Community
Participate
Working Groups
Build Identifier: I20100608-0911 I can run an Eclipse Application using TPTP if no AspectJ project is open. As soon as an AspectJ project is opened, Java crashes. I've tested it on Linux 32, Linux 64 and Windows 7 with Eclipse 3.6, AJDT 2.1.0 and AspectJ 1.6.9. # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f5c515220fe, pid=30819, tid=140034563962640 ... # Problematic frame: # C [libJIE.so+0x6f0fe] _ZN7CMethod12AddExceptionEP16CMethodExceptionN11CMtdExTable9Order_enuE+0x2e Reproducible: Always Steps to Reproduce: 1. Install AJDT and TPTP 2. Profile an Eclipse Application (like Eclispe itself with all plugins for the target platform) 3. Use the monitor: "Execution Time Analysis" 3. In the target Eclipse, create an AspectJ project.
We have tried several different ways to reproduce your problem, but in all cases, TPTP appears to be profiling while we create an aspectj project in a target platform. I am transferring this over to the TPTP team because they may have some ideas on how to reproduce and what the underlying problem is.
Transferring to TPTP project. Apologies if product and component are not correct.
Mike, Please take a look.
Seems the bytecode parser is having trouble with the following method: org/eclipse/ajdt/core/builder/AJBuilder#updateJavaCompilerPreferences In particular, the method exception table maps one of the handlers to IP=334. Our bytecode parser assumes that an handler start at a basic block. However, in this case there is a 'nop' instruction at IP=333 which is where we detect the beginning of the basic block: 333: 00 nop 3A 0C astore B8 05 38 invokestatic I have a tentative fix which is to alter the bytecode parser's semantic meaning of the 'nop' instruction from 'generic' to 'placeholder'. This causes the parser to treat the 'nop' as its own basic block, which then causes 334 to become a valid target for an exception handler: 333: 00 nop 334: 3A 0C astore B8 05 38 invokestatic More investigation need to understand the impact of this before we can declare it a final fix.
Created attachment 177043 [details] Patch to place each 'nop' in its own basic block
Created attachment 177044 [details] Bytecode of the offending class For easy reference, attaching the bytecode of the offending class. Method of interest is 'updateJavaCompilerPreferences'.
Thanks for looking into this. I wonder if this has something to do with the byte code created by AspectJ. The offending method contains a couple of empty catch blocks that are advised by an aspect. It looks like the bytecode parser is barfing on that.
we could tweak the bytecode output of AspectJ to get around this. just tidying up the nops would seem to help, in this case.
The nop is indeed what is tripping up the .class parser. I should maybe clarify my previous statement "causes 334 to become a valid target for an exception handler". I mean valid in the context of the TPTP bytecode parser. From what I can see in the JVM spec this is valid bytecode. It is in our interest to patch the bytecode parser, as we may encounter similar bytecode in the future. After review, the proposed approach is more of a hack than a correct solution. It seems the correct thing to do is to split the block only if we encounter this situation (the existing patch gives each 'nop' its own basic block). This preserves the definition of a basic block as a series of instructions which can only be entered/exited at its beginning and end points. This is however not quite so trivial, so will take a little bit more work to get a patch ready.
Created attachment 177897 [details] Split basic block if exception target doesn't map to beginning of a block The attached patch implements the solution described in comment 9. This appears to solve the problem.
Requesting we bring this forward for PMC approval: 1. Explain why you believe this is a stop-ship defect. How does the defect manifest itself, and how will users of TPTP / consuming products be affected if the defect is not fixed? This bug causes the profiler (and JVM) to crash when encountering certain bytecode produced by tools such as AspectJ. 2. Is there a work-around? If so, why do you believe the work-around is insufficient? No. 3. Is this a regression or API breakage? Explain. Not a known regression, prior releases would likely have this problem. 4. Does this require new API? No. 5. Who performed the code review? Jonathan West 6. Is there a test case attached to the bugzilla record? No. 7. What is the nature of the fix? What is the scope of the fix? What is the risk associated with this fix? The fix detects the presence of the uncommon type of bytecode and updates in-memory data structures to accommodate it, preventing the crash. The new code only executes if this situation is detected, so behaviour with bytecode already known to work is unaffected. Risk is low since the new code executes only in the problematic scenario. 8. Is this fix related to any standards that TPTP adheres to? If so, who has validated that the fix continues to adhere to the standard? No.
Requesting PMC approval for TPTP 4.7.1.
Patch checked into HEAD with PMC approval.
This defect had been resolved as FIXED for more than 1 month. Please verify with the latest TPTP 4.7.2 driver. If this defect is still left unverified by February 25, we'll close it on the originator's behalf. TPTP 4.7.2 driver can be downloaded from: http://www.eclipse.org/tptp/home/downloads/?ver=4.7.2
I'm the originator and it's working for my particular case. However, Mike Reid found the real problem and don't know how to test that the problem is really fixed at the byte code level. (In reply to comment #14) > This defect had been resolved as FIXED for more than 1 month. Please verify > with the latest TPTP 4.7.2 driver. If this defect is still left unverified by > February 25, we'll close it on the originator's behalf. > > TPTP 4.7.2 driver can be downloaded from: > > http://www.eclipse.org/tptp/home/downloads/?ver=4.7.2
(In reply to comment #15) > I'm the originator and it's working for my particular case. > > However, Mike Reid found the real problem and don't know how to test that the > problem is really fixed at the byte code level. > The fact that Java no longer crashes when using a TPTP build that contains this fix indicates the problem is resolved. Given your comment that the crash no longer occurs, I'll go ahead and close this. Please re-open if you are still experiencing the crash.
