Q: How analyze compiler crash? #3522
Comments
Did you check earlier in the Maven logs that the compiler itself didn't log an error? This should be no different from when you have an error in your code making it impossible to compile.
You can disable all checks with |
|
-XepDisableAllChecks does not help unfortunately. The compiler does not write out any messages, see log. The project uses lombok, maybe a problem? I cannot remove Lombok from the evaluation. On an Ubuntu running WSL2, the compiler behaves no differently.
|
|
The way I debug such things (it could be that Maven is "eating" the logs too) is to run Maven with debug logs (
|
|
Thank's for the Tipps. When I call the compiler from the cli I get this error:
The CLI looks like this:
|
|
The |
|
Shit, I should have seen that myself. The problem is here: Open a ticket, or is this question issue enough as a ticket? |
|
That's #1250, caused by Lombok. Workaround: disable the UnusedVariable check. |
|
In my case The next problem is Also lombok @tostring as described here , but unfortunately the -XepDisableWarningsInGeneratedCode option doesn't work for me here. |
|
Note that those errors also depend on your version of Lombok. |
|
@tostring removed for now and now the compiler runs through without any further messages as if the 2000 classes are ok. |
|
In case someone else stumbles across this: I also had a very similar error without any details: In my case, the problem seems to be the Toolchains plugin that is used to set the Java version for the project. As soon as I remove the plugin and rely on the default JDK (which is actually the same as the one set via the plugin), compiling works as expected (or runs into a Lombok issue that comes with some description). |
|
@andreassiegel does running the toolchain setup with I'm asking because coincidentally I just started playing with such a setup, and I noticed that it does not seem to be compatible with multi-line arguments to |
|
^ This newline issue isn't specific to a Toolchain setup; it can also be reproduced without if one enables forking ( |
|
@Stephan202 Thank you, I used it to compare the runs with toolchains plugin and without, especially the command-line options for javac. The interesting observation is that the command apparently gets messed up when the toolchains plugin is involved. For better readability, I added a few line-breaks. Output without toolchains plugin: When the toolchains plugin is involved, the output looks as follows: Note the line between So, at least in my case, multi-line arguments for ErrorProne aren't an issue. I just wonder what causes that difference, and how to fix it (or if that actually is an issue at all). Edit: Calling javac directly with JDK 17 or 19 leads to this error: This does not occur when JDK 11 is used. The reason for that is that the additional configuration in So I finally got it working by defining the flags in the <compilerArgs>
<arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED</arg>
<arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED</arg>
<arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED</arg>
<arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED</arg>
<arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED</arg>
<arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED</arg>
<arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED</arg>
<arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED</arg>
<arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED</arg>
<arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED</arg>
<arg>-XDcompilePolicy=simple</arg>
<arg>-Xplugin:ErrorProne</arg>
</compilerArgs> |
|
Very nice that you figured it out @andreassiegel! For the more general issue that compiler failures sometimes happen without clear output, codehaus-plexus/plexus-compiler#66 may be an issue to keep an eye on. |
|
Sorry for resurrecting the issue, but I am also looking for general advice on debugging a compiler failure. We see intermittent compilation errors in a Maven project with >450 modules when Error Prone is enabled. It doesn't prove the issue is in Error Prone, but it may be more likely to happen when Error Prone is enabled. I couldn't reproduce when Error Prone is enabled, but all bug patterns are disabled ( It seems it fails at the There is no pattern for error either. There are jobs we got There are also errors that might indicate a potential race condition:
IIUC, in a multi-threaded build, maven-compiler-plugin creates a new I disabled a few things and made sure that the source files were not corrupted before the Maven build, but still, there are a few layers that can cause the issue:
It usually happens when we build all (or almost all) modules in a CI job. I still couldn't reproduce it locally, but I can reproduce it 2-3% of the time on CI for a full build. The overall failure rate is less than 1%. But it's still quite annoying and confusing for developers working on the project. So, I would appreciate some pointers on debugging it further or how to reproduce it locally. |
|
You could probably rule out the "shared non-thread safe instance" option by configuring maven-compiler-plugin to fork (you'll probably have to copy the Also, are you using Maven's parallel builds? If so, you could also try disabling them to possibly rule out concurrency issues. |
|
Thanks for the swift answer!
That's a good point. I will try that next.
Yes, it's a parallel build with thread count of 4. |
|
Sorry for the late response. Indeed, forking javac indicates it's a concurrency issue. But we cannot afford forking javac for 450+ modules. It's extremely slow compared to in-process compilation. I enabled forking for the module where we get most of the errors to see if others will start failing due to intermittent compilation errors. And there was one interesting failure: There is no module called I think the error comes from this line: https://github.com/openjdk/jdk/blob/jdk-17%2B19/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L1087-L1089 |
See google/error-prone#3522 for details why this test exists. TL;DR error-prone may or may not break with toolchains enabled for some reason.
My first attempts with error prone: on Windows 10, OpenJDK 17 17.0.5, maven wrapper 3.8.6, maven-compiler-plugin 3.10.1, 2290 source classes. The compiler mojo ends up with error without error messages:
How can I approach the cause of the error? Is there a debug logging? Can the code checks be activated individually to identify the faulty check?
The text was updated successfully, but these errors were encountered: