Re: [platform-debug-dev] Debug Event Processing

["Darin Wright" <Darin_Wright@xxxxxxx>]

Unfortunately, I do not believe this fix is safe - a potential deadlock exists.

During the entire 'toString()' evaluation, the target thread will be "locked". If the evaluation ever gets into an infinite loop or deadlock, the target thread will not be accessible from the UI. That is, if a user tries to suspend the thread manually, or another (Eclipse) thread makes a request on the thread (for display purposes), those threads will also be deadlocked, potentially causing the Eclipse UI to hang. In theory, 'toString()' evaluations should be simple & fast (and no breakpoints are hit in this evaluation). Thus, most of the time, this will work - but the deadlock danger still exists.

I verified the deadlock problem exists by creating an infinite loop in a 'toString' method, and selected that object in the variables view. If I then selected the "suspended" thread in the debug view, Eclipse hangs.

Darin

David Sanders <dsanders@xxxxxxxxxxx> Sent by: platform-debug-dev-admin@xxxxxxxxxxx 07/17/2002 05:04 PM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx         cc:        jdt-debug-dev@xxxxxxxxxxx         Subject:        Re: [platform-debug-dev] Debug Event Processing

I recently ran into a related problem when wrappering the jdt debug
model.  All of our variables require a toString method to be called,
as none are primitives.  I noticed that instead of the toString value,
I often recieved an error message in the details window.  To solve the 
problem, I added a synchronize on thread in the detailsRunnable of 
computeDetail in the presentation model code (see JDIPresentationModel):

synchronized (thread)
{
    thread.runEvaluation(er, null, DebugEvent.EVALUATION_IMPLICIT,
false);
}

This seems to have fixed the problem, but I'm not sure if it is the
best fix for what you are describing.

Regards,

David

---
David Sanders
LegacyJ, Corp.


Darin Wright wrote:
> 
> The Java debugger exhibits a known problem with regards to displaying
> the details or 'toString' of a selected variable or _expression_. The
> specific scenario is as follows:
> 
> (1) The variables view receives a "suspend event"
> (2) The variables view asks the Java debug presentation for the
> details for the selected variable
> (3) The Java debug presentation starts an asynchronous evaluation in
> the thread that just suspened to obtain the 'toString' of an object
> (4) Susequent event listeners are informed of the "suspend event".
> However, at  this point the thread can actually be running, due to the
> implicit evaluation calculating the 'toString'. This can cause event
> listeners to randomly fail when processing events. The failure is not
> predicatable, as the problem is timing dependent. For example, the
> debug view may attempt to render the stack frames for a thread, but
> the thread is running (and has no stack frames).
> 
> The above problem can be generalized: If an event listener changes the
> state of a debug model, subsequent event listeners are informed of an
> event which is now out of synch with the debug model. Furthermore,
> many event listeners are in the UI and perform UI updates. Such
> listeners often submit async runnables to the Display, which are run
> at a later time. There is no guarentee that the debug model is in the
> same state when  a runnable is executed, as when the associated debug
> event was reported.
> 
> This is a similar problem to workspace modification. That is, when a
> resource change callback is taking place, the workspace cannot be
> modified. As well, only one client may modify the workspace at a time
> (i.e. a client obtains a lock on the workspace in order to modify the
> workspace).
> 
> Ideally, event processing would occurr as follows:
> (1) All event listeners are informed of an event set
> (2) All UI updating based on the event set is completed (updates are
> not allowed to change the state of the debug model).
> (3) Any event listeners that need to perform operations on the debug
> model are run serially (for example there could be multiple views
> requiring implicit evalautions to be run).
> 
> Discussion/proposals on how such an infrastructure could be
> implemented are welcome (I'm still working on my proposal).
> 
> Darin
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev