JDK-4420844 : JPDA: Debugger operations after VM death cause errors
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 1.0,1.3.1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2001-03-02
  • Updated: 2002-08-30
  • Resolved: 2002-08-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other Other
1.3.0_04 04Fixed 1.3.1_01Fixed 1.4.0Fixed
Related Reports
Duplicate :  
JDK-4367942 - Stopping a HotSpot debug session leaves behind a javaw.exe.
Relates :  
JDK-4409562 - JVM crashed when debugging in Forte
Description
Between VM death (JVMDI_EVENT_VM_DEATH) and JDWP disconnection
is a time window wherein the VM is shutting down (and is therefore
unstable) and commands can still be sent across JDWP.

There is one easily reproducible case in which a JDI client has set
a breakpoint and requested class prepare events (SUSPEND_ALL).  
On the VMDeathEvent the client does clean up which includes attempting
to delete the breakpoint.  Since in Ladybird the VMDeathEvent is 
SUSPEND_NONE, the VM has proceeded and is now deep in its death.
The class prepare has prevented the death from completing to the
point of disconnection because the Shutdown class has been loaded.
At this point the breakpoint has been thrown away as part of VM 
shutdown so the breakpoint delete raises a JVMDI_ERROR_NOT_FOUND - 
which is an internal error.  This is probably one of many possible 
such scenarios.

abhijit.saha@Eng 2001-07-02

updating the bugtraq for bugs integrated in appropriate version of jdk.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.3.0_04 1.3.1_01 merlin-beta FIXED IN: 1.3.0_04 1.3.1_01 merlin-beta INTEGRATED IN: 1.3.0_04 1.3.1_01 merlin-beta VERIFIED IN: 1.3.0_04
14-06-2004
EVALUATION Currently VMDeathEvent can only be a SUSPEND_NONE event. Thus, what VMDeathEvent means is that a VMDeath occurred sometime in the past. It's only real use at present is as if it was a flag on VMDisconnectedEvent saying "I died nicely". In turn, this means there is no way for an application or even the front-end to know is is NOT after a VMDeath. For this reason, it would seem it must be the responsibility of the back-end to gracefully deal with whatever gets thrown at it after VMDeath - after VMDeath resources may be released and finally the connection is disconnected. Thus JPDA has always had a vulnerability from commands coming in between the JVMDI VMDeathEvent and when the JDWP connection is terminated. We haven't been aware of it because this is a very small window. Because Forte was sending an event request cancel in response to VMDeathEvent they were unintentionally able to hit this window. It doesn't make much sense to explicitly disable the events because of a VMDeath but I could see how a clean style could lead to this, and it is not their problem it is ours. BTW: Requests like this after a VMDisconnectedEvent should throw a VMDisconnectException. But the SUSPEND_NONE of VMDeath is a problem here too because there is no way an app can guard against this. For this reason, I proposed, not long ago, to the JDI Review Task Force (external folk) that a VMDeathRequest be added in Merlin, this would allow SUSPEND_ALL VMDeathEvents, and thus synchronization; They unanimously approved (4419314). A workaround would be after all VMDeathEvents are sent (in eventHandler.c) but before eventHook returns, a flag is set that causes these rewuests to be ignored. This will work fine for commands that have no response (like event request cancel - the Forte case) but what are they to do for commands that do have a response? We should use this workaround for Ladybird. The right solution though falls out easily once VMDeathRequest is added in Merlin. The front-end can create an internal VMDeathRequest with a suspend policy of SUSPEND_ALL (the front-end already handles several internal requests/events), then once ALL VMDeathEvents have been handled it sets a flag, such that any further commands will cause VMDisconnectedException. The InternalEventHandler will need to be careful to not do a resume if there is a user created SUSPEND_ALL or SUSPEND_THREAD VMDeathRequest. robert.field@Eng 2001-03-01 begin - robert.field@Eng 2001-04-03 Because it could hang applications that did not read the VM death event, the approach of using VMDeathRequest cannot be used internally. This functionality has been added however and should be used by applications. Jim has placed in Suggested Fix the solution for Ladybird. For Merlin a similiar approach is taken, the back-end will not send any events after the VMDeathEvent and after the processing of that event completes, a flag is set that causes almost all commands to return the VM-dead error which the front-end converts to VMDisconnectedException.
11-06-2004
WORK AROUND
11-06-2004
PUBLIC COMMENTS JDWP commands sent after VM death cause errors
10-06-2004