| Summary: | [Martini/JPI] Dynamic class redefinition does not work with applications which use multiple class loaders | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | amehrega |
| Component: | TPTP | Assignee: | Asaf Yaffe <asaf.yaffe> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P1 | CC: | guru.nagarajan, jacek.pospychala, jkubasta, lizdancy, popescu, sluiman, viacheslav.g.rybalov |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | closed460 | ||
| Bug Depends on: | |||
| Bug Blocks: | 190802 | ||
|
Description
amehrega
Asaf - Can you take a look at this. The output on the console is [Error: EC JPIAgent received message (FATAL ERROR): Internal error (see log file).] This issue is related to the logic used inside Martini for redefining loaded classes (which happen during attach/detach). It may be related to the Eclipse/OSGi framework as we have yet to observed this failure with other Java application types. I need more time to root-cause this failure. The root-cause of this bug is that during detach (or attach), the current implementation for redefining loaded classes may need to force-load some classes into memory (specifically, classes which were already instrumented but not yet prepared). To force-load classes, the implementation calls the JNI FindClass function which uses the Java bootstrap class loader. This does not work in applications such as Eclipse, where each plugin manages its own classes with a specific class loader. This bug will also prevent the JVMTI CPU and Heap profilers from attaching to a running workbench (this is not a detach-specific bug). It may also manifest itself in other applications which uses multiple class loader to achieve some sort of component isolations (e.g, J2EE servers). I have implemented and checked-in a workaround that does not require class redefinition. Attaching to/detaching from the CPU and Heap Profilers no longer cause crashes. Retargeting bug to the next iteration. Changing bug severity from "critical" to "major" as a workaround is available. raising sev Ali, given the workaround available, is this a candidate for deferral? Detaching the agent doesn't cause process termination but when the user right clicks a detached agent and clicks "Attach to Agent", the process terminates and the following exception is displayed: java.lang.NullPointerException null java.lang.NullPointerException at org.eclipse.tptp.platform.jvmti.client.internal.launcher.TIDelegateHelper.attachToAgent(TIDelegateHelper.java:574) at org.eclipse.tptp.platform.jvmti.client.internal.launcher.TIDelegateHelper.attachToAgent(TIDelegateHelper.java:538) at org.eclipse.tptp.platform.jvmti.client.internal.controlproviders.TIAgentControlProvider$TIAgentStateModifier.doAction(TIAgentControlProvider.java:321) at org.eclipse.tptp.platform.jvmti.client.internal.controlproviders.TIAgentControlProvider$TIAgentStateModifier.performCollectiveAction(TIAgentControlProvider.java:271) at org.eclipse.tptp.platform.jvmti.client.internal.controlproviders.TIAgentControlProvider$TIAgentStateModifier.attach(TIAgentControlProvider.java:221) at org.eclipse.tptp.trace.ui.provisional.control.provider.AbstractAgentControlProvider$1$AttachControlItem.run(AbstractAgentControlProvider.java:108) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:545) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:490) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:402) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) ... (In reply to comment #7) The problem described by Ali is not related to this bug. Recommend to lower priority of this bug and defer to future. Joanna, Assuming Assaf is right, I think we need to open a separate critical defect (on the JVMTI client side) and have the severity of this defect lowered to major. There already appears to be a defect open for the problem that I've mentioned: https://bugs.eclipse.org/bugs/show_bug.cgi?id=186807 Changed summary to better describe the bug Must be fixed in 4.4.0.1 to enable Bug 190802 which is also scheduled for 4.4.0.1 Lowering the priority on this defect. We are addressing P1's for 4.4.0.1 Triaging 4.4.0.2 candidate defects for Joanna. This is a 4.4.0.2 candidate defect since deferred from 4.4.0.1. Asaf, please target to 4.4.0.2 when the field is available. Cannot be contained in 4402 Resolved. The current fix does not support IBM 1.5 JVM as it does not properly support the JVMTI RedefineClasses API. (In reply to comment #16) > Resolved. > The current fix does not support IBM 1.5 JVM as it does not properly support > the JVMTI RedefineClasses API. So in conclusion this problem is now just pending an IBM JRE fix an dis not restricted to OSGi as noted in the Summary? If there is also an outstanding OSGi problem, it should be tracked separately as this will obviously affect any Eclipse or RCP developer. (In reply to comment #17) > So in conclusion this problem is now just pending an IBM JRE fix an dis not > restricted to OSGi as noted in the Summary? That's correct. The fix resolves all known issues with OSGi/Eclipse-based applications. (In reply to comment #18) > > That's correct. The fix resolves all known issues with OSGi/Eclipse-based > applications. > Thanks Asaf for the clarification. Can you update the bug summary then to reflect this. It seems the reference to OSGi is no longer needed and the bug was broader Changed bug summary to better describe the problem. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |