Community
Participate
Working Groups
Build Identifier: I20110613-1736 Sometimes when I change the active build configuration from the project's main menu " Build configuration -> Manage..." I have a JVM crash. I tried with different version of Oracle Java and it happens with all JVM version - 1.6.0_14 or higher. The messages is in the hs_err*.log file is: ... Current thread (0x34031400): JavaThread "C1 CompilerThread0" daemon [_thread_in_native, id=6612, stack(0x349e0000,0x34a30000)] ... Current CompileTask: C1: 161984 7294 org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPVisitor::createType (584 bytes) ... Looks to me that is it some kind of JVM bug that under certain conditions chokes while compile the method org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.CPPVisitor public static IType createType(IASTDeclarator declarator) The method looks rather long, compared to the other methods of the class so I tried splitting it in three part. The experiment worked! The JVM crash doesn't happen if the method is split in few parts. I found references to JVM crashes "C1 CompilerThread0" that have been existing in different JVM versions and still exist. The JVM crash only happens with specific projects - it looks it is very sensitive on what header files are being parsed. Reproducible: Always Steps to Reproduce: see details.
I've also reported a bug for this, which was closed with NOT_ECLIPSE. https://bugs.eclipse.org/bugs/show_bug.cgi?id=357757. I also reported a bug with Oracle, which can be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7090976 The workaround is to exclude the offending method from compilation, like this: -XX:CompileCommand=exclude,org/eclipse/cdt/internal/core/dom/parser/cpp/semantics/CPPVisitor,createType
Considering: 1. that the java bug is not fix yet; 2. whenever it get fixed, customers will still have older version of JRE for years; 3. there is a simple workaround – just make the function shorter by introducing few smaller helper functions 4. the workaround conform to java practices, not too make functions too long; Does it makes sense for a committer to implement the workaround?
I am able to reproduce the crash only with our custom product: It can be downloaded from the site: http://processors.wiki.ti.com/index.php/Download_CCS Install the 5.1 Release Candidate at the top of the web page. Make sure you remove/rename the JRE folder that gets installed inside the Eclipse folder. Make sure the default JRE is higher than 1.5.13. Start Code Composer. In the “CCS Edit” go the main menu “CCS Example Projects”. In the edit box on in the top left type “grace”. The tree view show projects that are have the specified keyword. Start selecting each of the lead nodes and then click on the “Import the example project” on the right pane. The JVM crashes after importing for about 7 to 10 project. There is something specific in the library header files as well as the timing to get the JVM crash. I wander if Jesper Eskilson has a use case that is reproducible in the Open Source?
In term of submitting a patch I believe the JRE just doesn’t like big functions. I tried experimenting with splitting the function in three parts and it worked. The problem is that to pass variables between all three part of the split function I created an ugly class to keep those locals. I think the real patch should have make meaningful split in functions, than just cutting the function in three with the ax.
(In reply to comment #4) > In term of submitting a patch I believe the JRE just doesn’t like big > functions. > I tried experimenting with splitting the function in three parts and it worked. > The problem is that to pass variables between all three part of the split > function I created an ugly class to keep those locals. > I think the real patch should have make meaningful split in functions, than > just cutting the function in three with the ax. Then why does it fail in your custom product and nowhere else? I don't see these errors.
> (In reply to comment #4) > Then why does it fail in your custom product and nowhere else? I don't see > these errors. I think it has to do with the content of the header files as well as timing, when the parsing has to switch from one project/ configuration to another - I need to start another parsing while one parsing is happening. I did one very simple experiment – I removed all include statements from the projects files and I don’t have the crash. Tracing which statement in which header file get it to crash may be too much. I guess at the end of the day we know the CDT fix/workaround - splitting the method in few parts. I don’t think we can rely in Java fixing it – for a long time user will have older JREs.
(In reply to comment #5) > Then why does it fail in your custom product and nowhere else? I don't see > these errors. Neither do my 1000+ users.
I've split CPPVisitor.createType(IASTDeclarator) into two methods in cdt_8_0. Please let me know if that helps.
(In reply to comment #8) > I've split CPPVisitor.createType(IASTDeclarator) into two methods in cdt_8_0. > Please let me know if that helps. Thanks a lot, Sergey. The change fixed the JVM crash.
I'm closing this bug since a workaround for the JVM bug has been provided.
I received an email from the responsible engineer assigned to the bug I reported (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7090976): "This was bug over in the wrong category so it's just now gotten to the right group. Are you still able to reproduce this? Can you give a script that would reproduce it? Intermittent failures are fine and it doesn't have to be minimal, just as long as it crashes. If not, could you give me a mini dump from a crash using -XX:+CreateMinidumpOnCrash. Thanks." I'll try to set up a minimal test case, but haven't been successful so far. If anyone has or can create a test case (or a mini dump), let me know so I can forward it to Oracle.
I posted a link on the Oracle bug link: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7090976 to the user case I provided in this bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=360855#c3
(In reply to comment #3) > I wander if Jesper Eskilson has a use case that is reproducible in the Open > Source? Unfortunately not. I'll try to see if I can isolate something, but so far I have been unsuccessful.
Another update from Tom Rodriguez at Oracle. He has found and fixed the problem: "I just updated the bug report. It's a very old bug with an optimization around invokeinterface. It's trying to improve the types used in the invoke by looking at the implementors of an interface but picking the wrong types because it's not searching broadly enough. The code we emit has guards that verify the type so even if we pick the wrong types we can't actually execute wrongly. What happens here is that as a side effect of the guarding logic we treat an object as two different types and emit loads that happen to have the same offset but different types and one is substituted for the other which is what causes the compiler crash. So the bug itself can only cause a compiler crash if you get a particular confluence of types and fields and they happen to be at the same offset. The bug itself should be very reliable. If a refactoring has caused it to disappear from eclipse then it shouldn't occur again. It should be fixed in 7u4 and I'll see about getting it back ported to 6 as well. Thanks for filing the bug."
