Community
Participate
Working Groups
Created attachment 90395 [details] Workspace .log file Build ID: I20080207-1530 I'm getting a StackOverflowError whilst working with a particular file "ManagePerformancesDialog" in the project that I'm working in. The error _only_ occurs when editing this file, which I've never had cause to open until now. Aside from being fairly long (8000 lines) I can't see anything particularly unusual with it. When opening the file I get "Exception in thread "org.eclipse.jdt.internal.ui.text.JavaReconciler" java.lang.StackOverflowError" stacktrace to stderr [load.txt]. This is followed with a "Multiple Errors have Occurred" and "Internal Error" dialog warning me of the error and recommending I close the workbench. If I persist then the error re-occurs every 10 seconds or so as I click through the file. I've attached my .log file [log.txt] with the full details. Also, if I hover over text in the file I get "Exception in thread "Text Viewer Hover Presenter" java.lang.StackOverflowError" to stderr [hover.txt]. This is preventable by turning off the hovers using the Java > Editor > Hovers preference. I've checked out the latest org.eclipse.jdt.core soruce from CVS and the problem persists when running Eclipse with this. Both exceptions occur when org.eclipse.jdt.internal.compiler.lookup.FieldBinding.constant(FieldBinding.java:205) calls itself until the StackOverflowError kicks in. I had a go at debugging and the error is only raised when the code is dealing with a particular value for the originalField variable, which happens to be an enum constant. Bizzarely, the enum constant in particular and its declaring enum aren't even referenced by the file I'm working with. I appreciate that this is likely to be hard/impossible to reproduce since I myself only get the issue with one file. Any suggestions folk can offer on how I can produce an isolated test case would be much appreciated. Similarly, if there's any other debug info you'd like to see or any other debugging steps that I should take then I'd be very happy to help.
Created attachment 90396 [details] Exception stacktrace to stderr
Created attachment 90397 [details] Exception stacktrace to stderr
Do you have a regression test for this ? This could happen if the original field binding is equals to the current field binding. Any idea, Kent ?
This the .log doesn't show the build id, could you please specify the build id? Thanks.
Thanks for the quick response. I'm using 3.4M5. As per my original report this shows as I20080207-1530 in Help > About (I presume this is id you're looking for?). I had a copy of Eclipse 3.3 (I20070621-1340) lying around and the bug also occurs in this. Had another look at things this morning (GMT). Oliver is correct that the problem only occurs when originalField == this. This makes sense because originalField = this.original() [line 195], and this.original() just returns this [line 342]. I've discovered that the problem doesn't occur all the time for the particular enum constant that's giving me grief: sometimes originalField.constant is non-null (a DoubleConstant with value NAN) which allows the recursive call to FieldBinding.constant() [line 205] to break out. It's when it's null that I get the infinite recursion. Again, anything I can do to help just let me know.
If you could isolate the problem in a small test case with steps to reproduce, it would be really helpful. Thanks for the build id. This is exactly what I was looking for.
Philippe - can we replace the recursive call in FieldBinding.constant() with fieldConstant = originalField.constant == null ? Constant.NotAConstant : originalField.constant; It passes all of our tests.
This feels a good change.
*** Bug 225952 has been marked as a duplicate of this bug. ***
Created attachment 95246 [details] Fix as described by Kent in comment 7 I wrote a patch (attached) as per Kent's suggestion in comment 7. I applied this to the code in HEAD and re-built the org.eclipse.jdt.core plugin. I'm pleased to say that it fixed the bug in my case; I can now successfully edit and compile my problem file. I've been running the patch for a few days now and so far I've not seen any regressions caused by the change. Thanks for the help!
Released into HEAD for 3.4M7
Backported to 3.2 & 3.3 maintenance branches.
Was verified for 3.4M7 by reporter (comment 10)
