Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 179354

Summary: [Martini/JPI] Dynamic class redefinition does not work with applications which use multiple class loaders
Product: z_Archived Reporter: amehrega
Component: TPTPAssignee: 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 CLA 2007-03-26 14:21:01 EDT
- Profile the Eclipse workbench
- Detach the agent

Notice that the process terminates instead of the agent detaching.
Comment 1 Guru Nagarajan CLA 2007-03-26 19:59:54 EDT
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).]
Comment 2 Asaf Yaffe CLA 2007-03-27 06:21:54 EDT
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.
Comment 3 Asaf Yaffe CLA 2007-03-29 14:44:27 EDT
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).
Comment 4 Asaf Yaffe CLA 2007-04-22 10:38:23 EDT
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.
Comment 5 jkubasta CLA 2007-05-28 12:33:14 EDT
raising sev
Comment 6 jkubasta CLA 2007-05-28 15:54:59 EDT
Ali, given the workaround available, is this a candidate for deferral?
Comment 7 amehrega CLA 2007-05-28 16:36:08 EDT
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)
...
Comment 8 Asaf Yaffe CLA 2007-05-29 01:57:52 EDT
(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.
Comment 9 amehrega CLA 2007-05-29 10:18:06 EDT
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.
Comment 10 amehrega CLA 2007-05-29 10:32:16 EDT
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
Comment 11 Asaf Yaffe CLA 2007-06-20 05:24:07 EDT
Changed summary to better describe the bug
Comment 12 Asaf Yaffe CLA 2007-06-21 02:19:28 EDT
Must be fixed in 4.4.0.1 to enable Bug 190802 which is also scheduled for 4.4.0.1
Comment 13 Guru Nagarajan CLA 2007-06-29 14:17:01 EDT
Lowering the priority on this defect.
We are addressing P1's for 4.4.0.1
Comment 14 Paul Slauenwhite CLA 2007-07-16 09:11:07 EDT
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.
Comment 15 Guru Nagarajan CLA 2007-08-03 01:59:27 EDT
Cannot be contained in 4402
Comment 16 Asaf Yaffe CLA 2007-08-23 06:41:00 EDT
Resolved.
The current fix does not support IBM 1.5 JVM as it does not properly support the JVMTI RedefineClasses API.
Comment 17 Harm Sluiman CLA 2007-08-23 07:15:26 EDT
(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.
Comment 18 Asaf Yaffe CLA 2007-08-27 04:28:33 EDT
(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.
Comment 19 Harm Sluiman CLA 2007-08-27 08:53:29 EDT
(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
Comment 20 Asaf Yaffe CLA 2007-08-27 09:23:33 EDT
Changed bug summary to better describe the problem.
Comment 21 Paul Slauenwhite CLA 2009-06-30 13:47:32 EDT
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.