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

[David Sanders <dsanders@xxxxxxxxxxx>]

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