Community
Participate
Working Groups
I have the following error in my error log eclipse.buildId=4.4.0.I20140318-0830 An internal error occurred during: "Java Search". java.lang.StackOverflowError at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.mentionsAny(ParameterizedTypeBinding.java:915) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.mentionsAny(ParameterizedTypeBinding.java:915) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.mentionsAny(ParameterizedTypeBinding.java:915) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.mentionsAny(ParameterizedTypeBinding.java:915) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.mentionsAny(ParameterizedTypeBinding.java:915) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.mentionsAny(ParameterizedTypeBinding.java:915)
It happens when I right click on a specific .java file in the package explorer and select References -> Project The class looks like this final class Constants { private Constants() { throw new AssertionError("not instantiable"); } static final String PERSISTENCE_UNIT_NAME = "persistence.unit.name"; }
(In reply to Philippe Marschall from comment #1) > > final class Constants { Unable to reproduce with the given class; but that's because this issue is found at a ParameterizedTypeBinding. We would have to probably identify that expression. Srikanth: Since this looks like a type inference issue, could you please take a look at this?
Created attachment 241914 [details] Project to reproduce the issue A project to reproduce the issue. You need to have m2eclipse installed. - Select "Constants.java" in the package explorer - Right click -> References -> Project
Manoj, Please take a look.
Manoj, you might have seen that classes like TypeVariableBinding have a flag inRecursiveFunction to avoid this kind of infinite recursion. PTB doesn't have such a field, because we don't expect *directly* recursive PTB, recursion should only be possible via a TVB or WB (oops: WB.mentionsAny doesn't use its flag).
Created attachment 242113 [details] Modified org.eclipse.jdt.core.*.jar plugin (In reply to Stephan Herrmann from comment #5) > WB.mentionsAny doesn't use its flag). Thanks a lot, Stephan. I am attaching the jdt.core.jar file with this modification incorporated for trying out. Philippe: Local reproduction of the issue was not successful. However could you please use the attached org.eclipse.jdt.core.*.jar file instead of the current jar to check whether the problem exists with that file.
This issue is still happening with the modified jar.
(In reply to Philippe Marschall from comment #7) > Do you have any dependent jars for this project which you can share? If its big, you can share it privately as well to my email address.
(In reply to Manoj Palat from comment #8) > Philippe: Better still if you can do the following: - Create a new workspace with this project alone and reproduce the issue. And Please send/upload in bug the entire workspace.
Moving to 4.5
Created attachment 242364 [details] Workspace to reproduce the issue To reproduce the issue: * you need to have Maven to download the third party JARs from Maven Central http://maven.apache.org/download.cgi#Installation * run the following command to download the third party JARs from Maven Central mvn dependency:resolve dependency:sources * select com.github.marschall.threeten.jpa.Constants.java in the src/test/java folder in the Package Explorer * right click -> References -> Project $ java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
Manoj, see if you are able to reproduce using the description in comment#11 and if yes, evaluate a fix for 4.4. I am worried that this problem could show up outside the context of a search problem also.
Created attachment 242549 [details] feature patch Could not reproduce locally. The PTB.java:915/mentionsAny() is not being hit even. Philippe:please apply the feature patch and check out the messages (prefixed by PTB) to get more info and paste the last few messages here.
*** Bug 434800 has been marked as a duplicate of this bug. ***
The problem is still reproducible even with the feature patch applied. I get the same StackOverflow when trying to build the entire workspace (which contains quite a few projects). Projects become red saying "The project cannot be built until its prerequisite X is built.". Reproducible with JDK 8 (05) Works fine with JDK 7 (51) Was this pushed to Mars? To me it looks like a blocker.
(In reply to Georgian Grec from comment #15) > The problem is still reproducible even with the feature patch applied. I get > the same StackOverflow when trying to build the entire workspace (which > contains quite a few projects). If I understand Manoj correctly, the feature patch does not contain a fix but implements additional logging to narrow down the problem. (In reply to Manoj Palat from comment #13) > Philippe:please apply the feature patch and check out the messages (prefixed > by PTB) to get more info and paste the last few messages here. Can you find any matching messages in your logs? If so please post here. TIA.
Created attachment 244678 [details] Log after Manoj's feature patch I did just that, and from my POV there's not much to it in the log.
(In reply to Georgian Grec from comment #17) > I did just that, and from my POV there's not much to it in the log. Will give another patch to test asap
Created attachment 244708 [details] Luna Feature Patch Please find the modified feature patch for Luna. This should log messages with PTB prefix. I've used the latest standard release, that is eclipse-standard-luna-R-win32-x86_64(You would have to download this version and try it out). Let me know if you have issues for using this version.
Created attachment 244709 [details] Log after Manoj's second feature patch Tried your second feature patch against Philippe's project, comment #11 Although the project builds fine (unlike my heavy workspace, which just throws the stackoverflow when building), the problem is still reproducible when searching for references of the Constants.java
(In reply to Georgian Grec from comment #20) > Created attachment 244709 [details] > Log after Manoj's second feature patch > > Tried your second feature patch against Philippe's project, comment #11 > > Although the project builds fine (unlike my heavy workspace, which just > throws the stackoverflow when building), the problem is still reproducible > when searching for references of the Constants.java Thanks for the log Georgian. This feature patch did not have any additional fixes but had additional log messages to collect more info. And the good news is that I can reproduce this issue locally now and currently investigating.
Created attachment 244857 [details] Proposed Patch - WIP this patch contains a small reproducible test case [with the proposed solution as per comment 5] Stephan : Could you please take a look? I was also wondering whether an additional parameters.length > 0 check would help in mentionsAny() as an optimization for the most frequent case [if zero parameters is the most frequent]. Have added the check for WB as well in addition to PTB. Thanks.
preliminary comments: (In reply to Manoj Palat from comment #22) > this patch contains a small reproducible test case congrats! > I was also wondering whether an additional parameters.length > 0 check would > help in mentionsAny() as an optimization for the most frequent case [if zero > parameters is the most frequent]. I doubt that that is the most frequent case. Do you have any indications in that direction? > Have added the check for WB as well in addition to PTB. Thanks. Adding the check to WB didn't suffice?
(In reply to Stephan Herrmann from comment #23) > preliminary comments: Thanks Stephan for the comments. > > I was also wondering whether an additional parameters.length > 0 check would > > help in mentionsAny() as an optimization for the most frequent case [if zero > > parameters is the most frequent]. > > I doubt that that is the most frequent case. Do you have any indications in > that direction? I donot have enough data to say that this is the frequent case, though in this particular bug, there is no parameter - will not add this case - may put a comment. > > > Have added the check for WB as well in addition to PTB. Thanks. > > Adding the check to WB didn't suffice? It did not suffice to put the check in WB since the loop were through RTB-PTB . Will resubmit the patch after testing today.
Created attachment 244874 [details] Proposed Patch Same as the above except for some minor comments
Manoj, I'd prefer to avoid the "inRecursiveFunction" story in PTB, because normally a PTB can be recursive only via TVB or WB, right? What I see using your test case is, however, a recursion via a RawTypeBinding. We have this funny story that RTBs *may* have their "arguments" set, which is somewhat unexpected and confusing. Could you please investigate the alternative approach where RTB#mentionsAny ignores its #arguments, perhaps by copying the implementation from TypeBinding? The change in WildcardBinding, however, is good. Here we already have "inRecursiveFunction" and should indeed check this inside mentionsAny() - even though a change in RTB might suffice to fix this bug.
(In reply to Stephan Herrmann from comment #26) > We have this funny story that RTBs *may* have their > "arguments" set, which is somewhat unexpected and confusing. > > Could you please investigate the alternative approach where RTB#mentionsAny > ignores its #arguments, perhaps by copying the implementation from > TypeBinding? > Thanks for the comments, Stephan. And yes, as you mentioned, we can implement RTB#mentionsAny(). However, I would think that we can return false directly in RTB#mentionsAny() instead of copying the implmenentation from TypeBinding. What scenario am I missing here?
(In reply to Manoj Palat from comment #27) > (In reply to Stephan Herrmann from comment #26) > > > We have this funny story that RTBs *may* have their > > "arguments" set, which is somewhat unexpected and confusing. > > > > Could you please investigate the alternative approach where RTB#mentionsAny > > ignores its #arguments, perhaps by copying the implementation from > > TypeBinding? > > > > > Thanks for the comments, Stephan. And yes, as you mentioned, we can > implement RTB#mentionsAny(). However, I would think that we can return false > directly in RTB#mentionsAny() instead of copying the implmenentation from > TypeBinding. What scenario am I missing here? None, I guess :) I was thinking of mechanically undoing the override in PTB, but you're right, an RTB can never be equal to a type parameter, so, yes, returning false could suffice.
(In reply to Stephan Herrmann from comment #28) Thanks Stephan. Code committed via http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=22f68238a49995ff90d0a5b80069c5ce0a399d4d Georgian: Please use the latest build tomorrow to verify that the issue is resolved at your end.
fixed
Great to hear that it's working! :-) However, I cannot fully configure my workspace with 4.5 (N20140715-2000-win32-x86_64). Specifically, GlassFish tools won't install on Mars. They don't have a release for this version, yet. Could you please provide a feature patch with this particular fix? I want to apply it on Luna. Either mail it to me, or attach it here, when you have the time. Thank you!
(In reply to Georgian Grec from comment #31) (In reply to Manoj Palat from comment #30) Gregorian and Manoj, Great work tracking and fixing this. Can either of you provide any ETA on getting at least a beta patch up on the download pages? Our Java8 migration project has been blocked by this bug for several weeks, and we're eager to try-out the fix, hopefully it allows us to get the migration moving again. Promise to report back what we find :-).
(In reply to Richard Steiger from comment #32) > (In reply to Georgian Grec from comment #31) > (In reply to Manoj Palat from comment #30) > > Gregorian and Manoj, > > Great work tracking and fixing this. Can either of you provide any ETA on > getting at least a beta patch up on the download pages? Our Java8 migration > project has been blocked by this bug for several weeks, and we're eager to > try-out the fix, hopefully it allows us to get the migration moving again. > Promise to report back what we find :-). Richard: You can take any of the latest downloads (nightly) of eclipse - this fix would be included in that.
(In reply to Manoj Palat from comment #33) > (In reply to Richard Steiger from comment #32) > > (In reply to Georgian Grec from comment #31) > > (In reply to Manoj Palat from comment #30) > > > > Gregorian and Manoj, > > > > Great work tracking and fixing this. Can either of you provide any ETA on > > getting at least a beta patch up on the download pages? Our Java8 migration > > project has been blocked by this bug for several weeks, and we're eager to > > try-out the fix, hopefully it allows us to get the migration moving again. > > Promise to report back what we find :-). > > Richard: You can take any of the latest downloads (nightly) of eclipse - > this fix would be included in that. Hello Manoj. As I mentioned in a comment above, I would like this fix on 4.4, and not 4.5 integration builds. Since we're using the Luna for production code, we cannot afford an unstable Mars. I also tried the 4.4.1 M20140716-0800 (16 July 2014), but the fix isn't included there (should it?). We would appreciate if you provided Richard and I with a feature patch for 4.4 Thank you.
Manoj, thanks for pointing me to nightly builds. I've been using the latest Mars build for the last day, it appears stable, and we've restarted our j8 migration project. Thanks again, -rjs
(In reply to Richard Steiger from comment #35) > Manoj, thanks for pointing me to nightly builds. I've been using the latest > Mars build for the last day, it appears stable, and we've restarted our j8 > migration project. > > Thanks again, > > -rjs Thanks Richard. Great to know that you have checked out the latest Mars. Just to make sure we are on the same page. Do you still require this to be backported to 4.4 Luna (4.4.1 to be precise)? If yes, please let us know here. [Backporting is generally done only for regressions, and critical bugs - so if it is critical for you, we would backport it to 4.4].
Yes. The backport would be very helpful. I don't know about Richard, but for our system it is a blocker.
Reopen to backport to 4.4.1 Jay, OK with back port ?
(In reply to Srikanth Sankaran from comment #38) > Reopen to backport to 4.4.1 > > Jay, OK with back port ? Yep, Manoj please post a patch for R4_4_maintenance. Or let me know if the fix can straight away be be cherry-picked.
(In reply to Jayaprakash Arthanareeswaran from comment #39) > (In reply to Srikanth Sankaran from comment #38) > > Reopen to backport to 4.4.1 > > > > Jay, OK with back port ? > > Yep, Manoj please post a patch for R4_4_maintenance. Or let me know if the > fix can straight away be be cherry-picked. Thanks Jay for the green signal. Cherry Picked to R_4_4_maintenance via commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=R4_4_maintenance&id=56489f4301fc91391760f79a71fdfb45376254cc Georgian: you can download the latest luna maintenance (R_4_4_maintenance) bits.
cherry-picked for 4.4.1 as well. [Note: Original commit went for 4.5 M1]
Verified for 4.5 M1 using I20140804-2000 build
Verified for Eclipse Luna SR1 4.4.1 using M20140827-0800 build.
This bug has resurfaced in neon-1, neon-2, and oxygen-m5. It is a complete and total showstopper for us, started happening 2 days ago. It's triggered by a workspace rebuild, including spontaneous ones (not in response to editing). Currently running on jre1.8.0_121. I'll try other jre versions. Strange to see this bad boy resurface after almost 3 years. Thanks for any attention this gets. -rjs
(In reply to Richard Steiger from comment #44) > This bug has resurfaced in neon-1, neon-2, and oxygen-m5. It is a complete > and total showstopper for us, started happening 2 days ago. It's triggered > by a workspace rebuild, including spontaneous ones (not in response to > editing). > > Currently running on jre1.8.0_121. I'll try other jre versions. > > Strange to see this bad boy resurface after almost 3 years. > > Thanks for any attention this gets. > > -rjs Let's for a minute please consider that you may be observing a new bug, so we'd need to collect the typical information: stacktrace, ideally reproducing source code etc. Plus: the exact version of plug-in org.eclipse.jdt.core. TIA. Based on that information we can decide (a) reopen (b) file a new bug (c) do nothing.
