Community
Participate
Working Groups
Freshly built 4.9 SDK, on startup I see this in the error log. The code in question is from bug 521182. The MethodBinding "mb" is null. eclipse.buildId=4.9.0.I20180806-0300 java.version=1.8.0_181 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE Command-line arguments: -os win32 -ws win32 -arch x86_64 -data C:\workspaces\platform org.eclipse.core.resources Error Mon Aug 06 19:56:13 CEST 2018 Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.ast.ReferenceExpression.generateCode(ReferenceExpression.java:347) at org.eclipse.jdt.internal.compiler.ast.Statement.generateArguments(Statement.java:375) at org.eclipse.jdt.internal.compiler.ast.ExplicitConstructorCall.generateCode(ExplicitConstructorCall.java:173) at org.eclipse.jdt.internal.compiler.ast.ConstructorDeclaration.internalGenerateCode(ConstructorDeclaration.java:422) at org.eclipse.jdt.internal.compiler.ast.ConstructorDeclaration.generateCode(ConstructorDeclaration.java:294) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:572) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:642) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.generateCode(CompilationUnitDeclaration.java:410) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:900) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:142) at java.lang.Thread.run(Unknown Source)
(In reply to Andrey Loskutov from comment #0) > Freshly built 4.9 SDK, on startup I see this in the error log. > The code in question is from bug 521182. > The MethodBinding "mb" is null. So, java.lang.Object has no getClass() method. Do you have an idea which project / source code triggered this? Are you seeing compile errors like couldn't find j.l.Object?
(In reply to Stephan Herrmann from comment #1) > (In reply to Andrey Loskutov from comment #0) > > Freshly built 4.9 SDK, on startup I see this in the error log. > > The code in question is from bug 521182. > > The MethodBinding "mb" is null. > > So, java.lang.Object has no getClass() method. > > Do you have an idea which project / source code triggered this? > > Are you seeing compile errors like couldn't find j.l.Object? Yep. Since yesterday I've installed Java 10 and now I see all possible weird issues with that, I was not aware that this is *also* related. I had the mistake to have few JRE's configured in Eclipse for bug 532088 (1.4, 1.6, 1.7, 1.8, 1.9 and now 1.10).
(In reply to Andrey Loskutov from comment #2) > (In reply to Stephan Herrmann from comment #1) > > (In reply to Andrey Loskutov from comment #0) > > > Freshly built 4.9 SDK, on startup I see this in the error log. > > > The code in question is from bug 521182. > > > The MethodBinding "mb" is null. > > > > So, java.lang.Object has no getClass() method. > > > > Do you have an idea which project / source code triggered this? > > > > Are you seeing compile errors like couldn't find j.l.Object? > > Yep. Since yesterday I've installed Java 10 and now I see all possible weird > issues with that, I was not aware that this is *also* related. > > I had the mistake to have few JRE's configured in Eclipse for bug 532088 > (1.4, 1.6, 1.7, 1.8, 1.9 and now 1.10). Hm, if that causes trouble, we should definitely check why so! (btw, there is not 1.9, 1.10, only 9 and 10 ;p ). Anything special about your JRE 10? Which exact version? Any warnings on JRE or build path pages? On Execution Environments page, is it recognized as a perfect match for JavaSE-10? Build path errors on a project?
Created attachment 275294 [details] Java 10 project (In reply to Stephan Herrmann from comment #3) > Hm, if that causes trouble, we should definitely check why so! I'm trying... I can now build workspace, it seem that having a single (attached) project with Java 10 configured (and the rest just Java 8) causes a total mess and most of Java 8 projects will be red on a "Clean build". The root issue is reported as "The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files" on some of the projects, the rest is just dependencies of those. Closing this single Java 10 project, and clean build (few times) - no errors. > (btw, there is not 1.9, 1.10, only 9 and 10 ;p ). > > Anything special about your JRE 10? Which exact version? 10.0.2, latest was yesterday on Oracle > Any warnings on JRE or build path pages? Nope > On Execution Environments page, is it recognized as a > perfect match for JavaSE-10? Build path errors on a project? Yep.
(In reply to Andrey Loskutov from comment #4) > Created attachment 275294 [details] > Java 10 project Importing into a runtime workbench with latest JDT from master works fine, nothing suspicious. I'll get me a fresh latest SDK for testing ... > The root issue is reported as "The type java.lang.Object cannot be resolved. > It is indirectly referenced from required .class files" on some of the > projects, the rest is just dependencies of those. Yep, if you have that error, everything can happen. > > On Execution Environments page, is it recognized as a > > perfect match for JavaSE-10? Build path errors on a project? > > Yep. Yep to "recognized?" ? What about build path errors? If no build path errors, please try to open the JRE node either in Package Explorer or Libraries tab of Java Build Path. Does it show all normal modules?
All looks perfect with the JDK 10 on the UI side. After ~20 restarts and clean builds and index resets and project open/close actions I can't reproduce the problem anymore. It is my main platform workspace with many SDK projects inside.
(In reply to Andrey Loskutov from comment #6) > All looks perfect with the JDK 10 on the UI side. > After ~20 restarts and clean builds and index resets and project open/close > actions I can't reproduce the problem anymore. That's a pity (I mean: good for you, bad for debugging). Last chance to secure more traces: any other errors in your logs prior to the NPE? Other than that I don't see much we can do.
(In reply to Stephan Herrmann from comment #7) > Last chance to secure more traces: any other errors in your logs prior to > the NPE? No. > Other than that I don't see much we can do. Thanks, no problem. I wisch I could reproduce that.
Ok, this must be a regression happened recently. I've got same issue with another workspace, now on Linux, and without Java 10 involved. Out of the blue one project in Eclipse has shown "The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files" error, and the clean build on *that one* project caused all other projects to have same or related errors. The common denominator is the build id: I'm on I20180806-0300, and I believe I20180801-2000 or I20180731-2000 was last known good. I switch to the newest builds every one-two days, so I would have noticed this if this happened earlier. I use Java 8 for compilation/runtime, system is RHEL 7.4. This time I had two related NPE's in the log: eclipse.buildId=4.9.0.I20180806-0300 java.version=1.8.0_131 java.vendor=Oracle Corporation BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US Command-line arguments: -os linux -ws gtk -arch x86_64 org.eclipse.core.resources Error Tue Aug 07 12:51:08 CEST 2018 Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.ast.MessageSend.analyseCode(MessageSend.java:143) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.analyseCode(MethodDeclaration.java:125) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.internalAnalyseCode(TypeDeclaration.java:761) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.analyseCode(TypeDeclaration.java:265) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.analyseCode(CompilationUnitDeclaration.java:125) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:895) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:142) at java.lang.Thread.run(Thread.java:748) java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.ast.ConditionalExpression.generateCode(ConditionalExpression.java:287) at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.generateCode(LocalDeclaration.java:160) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:341) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.generateCode(AbstractMethodDeclaration.java:278) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:572) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.generateCode(TypeDeclaration.java:642) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.generateCode(CompilationUnitDeclaration.java:410) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:900) at org.eclipse.jdt.internal.compiler.ProcessTaskManager.run(ProcessTaskManager.java:142) at java.lang.Thread.run(Thread.java:748)
(In reply to Andrey Loskutov from comment #9) > Ok, this must be a regression happened recently. > > I've got same issue with another workspace, now on Linux, and without Java > 10 involved. > The common denominator is the build id: I'm on I20180806-0300, and I believe > I20180801-2000 or I20180731-2000 was last known good. > I'm seeing this more often, too. I suspect my patch for bug 525597. The change still looks safe too me, but it is e.g. possible that the previous behavior has masked another bug that now shows its effect. Especially, as I wrote, the containerPut seems suspicious to me. Maybe we should at least reset the project's cached resolved classpath.
Restarted same workspace with I20180801-2000 and all errors disappeared. The only changes in JDT between I20180801-2000 and I20180806-0300 were for bug 525597 and bug 532088: This change for bug 525597 touched container initialization: https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=01a4b5c420a65e3f6d91b552fdc7b8afc56d7998 The change for bug 532088 below simply replaced new String(String) calls in JDT: https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=fdff0425910a362eb56ee6287e38ac65a2bbe647 So my candidate is the change for bug 525597. The problem is, that I have no steps to reproduce: my both workspaces are pretty big and the problem appeared "out of the blue", and can't be reliably enforced. The common pattern was: existing workspace was used in a fresh SDK build (no update!).
(In reply to Andrey Loskutov from comment #11) > The common pattern was: existing workspace was used in a fresh SDK build (no > update!). I didn't understand what you mean here. BTW: I also can almost never replicate the problem (currently can't), but if a workspace has it, it is necessary to restart/build-all multiple times. If I have it again, I'll see if my suggestion from above fixes the problem. Another thing: even if the patch avoids builds on restarts, I *sometimes* see unnecessary at-least-almost-full builds when first saving a file or launching someting after a restart.
(In reply to Till Brychcy from comment #12) > (In reply to Andrey Loskutov from comment #11) > > The common pattern was: existing workspace was used in a fresh SDK build (no > > update!). > > I didn't understand what you mean here. I just noticed, that I saw the issue with two of my workspaces which I use for SDK patches and which I always run on (more or less) latest nightly SDK builds installed by "unzip" without any update or upgrade of existing installation. In the past I've encountered issues when I've tried to update my nightly SDK builds. > BTW: I also can almost never replicate the problem (currently can't), but if > a workspace has it, it is necessary to restart/build-all multiple times. Yes, probably yes, see my comment 6. > If > I have it again, I'll see if my suggestion from above fixes the problem. > Another thing: even if the patch avoids builds on restarts, I *sometimes* > see unnecessary at-least-almost-full builds when first saving a file or > launching someting after a restart. That can go in a dedicated bug report :-) Till: do we want to revert the patch for bug 525597 now, or do you have time to analyse this bug root cause (which seem to be closely related to container initialization)?
(In reply to Andrey Loskutov from comment #13) > Till: do we want to revert the patch for bug 525597 now, or do you have time > to analyse this bug root cause (which seem to be closely related to > container initialization)? As bug 525597 is pretty annoying and this one doesn't happen very often, we should focus on fixing this without reverting. And if it doesn happen more often, we'll be able to reproduce and fix it soon. In case you get it again first, can you try adding running with ((JavaProject) project).resetResolvedClasspath(); after the "IJavaProject project = entry.getKey();" in JavaModelManager.initializeAllContainers
New Gerrit change created: https://git.eclipse.org/r/127148
(In reply to Till Brychcy from comment #14) > > should focus on fixing this without reverting. And if it doesn happen more ... And if it >does< happen more ... (In reply to Eclipse Genie from comment #15) > New Gerrit change created: https://git.eclipse.org/r/127148 My guess as gerrit.
(In reply to Till Brychcy from comment #14) > As bug 525597 is pretty annoying and this one doesn't happen very often, I would say I can live with something building a bit longer but I can't live with something not building at all. I've got this on both my main SDK workspaces immediately after switching to 4.9.0.I20180806-0300 build. So I fear this could be a major issue. > In case you get it again first, can you try adding running with > > ((JavaProject) project).resetResolvedClasspath(); > > after the "IJavaProject project = entry.getKey();" in > JavaModelManager.initializeAllContainers I've never seen this in the debugger (yet), but I will check that.
(In reply to Andrey Loskutov from comment #17) > (In reply to Till Brychcy from comment #14) > > As bug 525597 is pretty annoying and this one doesn't happen very often, > > I would say I can live with something building a bit longer but I can't live > with something not building at all. I've got this on both my main SDK > workspaces immediately after switching to 4.9.0.I20180806-0300 build. So I > fear this could be a major issue. Sorry if I didn't understand you, can you still reproduce it or not?
(In reply to Till Brychcy from comment #18) > Sorry if I didn't understand you, can you still reproduce it or not? I can't reproduce but I'm scared to see that two fully independent workspaces on two different workstations show same issue immediately after switching to the new build.
(In reply to Andrey Loskutov from comment #19) > (In reply to Till Brychcy from comment #18) > > Sorry if I didn't understand you, can you still reproduce it or not? > > I can't reproduce but I'm scared to see that two fully independent > workspaces on two different workstations show same issue immediately after > switching to the new build. OK, sounded like you still cannot build at all. No need to be scared, this is only an integration build and M3 is about two weeks away. I wonder if downgrading and upgrading makes the bug reappear? Maybe this causes an immediate build on restart while the update is in progress which causes the race condition to appear?
(In reply to Till Brychcy from comment #20) > OK, sounded like you still cannot build at all. No, I can build *now* after several clean builds restarts etc or after switching to the build before. > I wonder if downgrading and upgrading makes the bug reappear? I had same idea, but at least on one workspace this not worked. > Maybe this > causes an immediate build on restart while the update is in progress which > causes the race condition to appear? The full build on the "SDK build switch" is *always* there because the target platform changes.
I have a workspace where the problem exists. The resetResolvedClasspath doesn't solve the problem.
Found it: In the runnable in JavaModelManager.initializeAllContainers, if the second containerIsSet-check (after initializeContainer) is true, only containerBeingInitializedRemove is invoked, but not containerRemoveInitializationInProgress (which is normally done as side effect of containerPut). Because of the ThreadLocals involved, only the Thread which did that then still gets CONTAINER_INITIALIZATION_IN_PROGRESS from containerGet and therefore e.g. JavaCore.getClasspathContainer returns the previousSessionContainer (if still present) or null to that Thread.
(In reply to Till Brychcy from comment #23) > Found it: Cool, let's keep our fingers crossed :) BTW, earlier today I briefly looked into the change from bug 525597, but soon got confused by the different synchronization mechanisms. Are you in a position to document, which lock protects what? Wouldn't that greatly help the next person working in that code area? Additionally, what you write sounds like some invariantish consistency constraints (if you remove this you must also remove that). Is it possible to verbalize those rules, too?
(In reply to Stephan Herrmann from comment #24) > (In reply to Till Brychcy from comment #23) > > Found it: > > Cool, let's keep our fingers crossed :) > > BTW, earlier today I briefly looked into the change from bug 525597, but > soon got confused by the different synchronization mechanisms. Are you in a > position to document, which lock protects what? Wouldn't that greatly help > the next person working in that code area? No wonder you're confused - As noted in my comments, the whole code is in my opinion currently not completely consistent. I was tempted to refactor it (actually started a bit), but then decided to keep the changes minimal for now, in case something like this bug appears ;-) I specifically added batchContainerInitializationsLock only for the purpose of synchronizing multiple threads in initializeAllContainers. The container* methods etc. are synchronized on the JMM instance. I could have used that in the new synchronized statements, but thought this would be really hard to follow. > > Additionally, what you write sounds like some invariantish consistency > constraints (if you remove this you must also remove that). Is it possible > to verbalize those rules, too? Hmm, besides the fact that those two names are confusingly close (probably cause of this bug), they are usually not removed at exactly the same time. Once initialization is done (taking into account recursive invocations) both should have been used.
Gerrit change https://git.eclipse.org/r/127148 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=9baccea1e09ccd17f92b0bc90f96b9a3a2cb6cf9
(In reply to Eclipse Genie from comment #26) > Gerrit change https://git.eclipse.org/r/127148 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=9baccea1e09ccd17f92b0bc90f96b9a3a2cb6cf9 Released for 4.9M3
@Andrey, it would be nice if you could verify that the problem is fixed in I20180807-2000
(In reply to Till Brychcy from comment #28) > @Andrey, it would be nice if you could verify that the problem is fixed in > I20180807-2000 I don't know if I will have time today at home (to check my Windows workspace), but at least on the Linux I see no problems so far with the new build. Crossing fingers :-)
So far the Windows workspace looks also fine. Thanks Till. Also I see no unexpected rebuilds anymore on startup.
Eclipse SDK Version: 2018-09 (4.9) Build id: I20180820-2000
