Re: [jdt-debug-dev] Weird stepping problem

["Darin Wright" <Darin_Wright@xxxxxxxxxx>]

There may be a timing issue that is appearing more frequently on one
platform than the other.

There are two things to be aware of here:
(1) You are modifying the state of the debug model during event dispatch.
(2) There are other event listeners that you are interacting with.

Generally, it is not good practice to modify the state of the debug model
during event dispatch, since other listeners (notified after your listener)
will not be able to properly update from the event notification. For
example, when there is a suspend event, other listeners may want to update
views (stack frames perhaps) - but your event listener has already started
another step, or resumed the thread. To help with this problem, the
DebugPlugin has a method that allows arbitrary runnables to be run after
event dispatch is complete - see DebugPlugin.asyncExec(Runnable). This
allows listeners to "schedule" runnables to be run after event dispatch.

There are some complexities involved in the Java debugger when it comes to
the display of details (toStrings()), in the variables view. The variables
view displays the result of performing an evaluation, i.e. toString(), on
the selected variable. A thread in the target VM is used to perform the
evaluation (which effectively resumes the thread to perform the
evaluation). This Java debugger schedules this evaluation to run after
event dispatch (using the above mentioned method in the DebugPlugin). The
scheduling of this evaluation is further complicated by the fact the the
debug views actually update asynchronously in the UI/Display thread. Thus,
the evaluation is "scheduled to be scheduled", after views have updated.
(See the code for more details).

It is possible that your code is failing due to interactions with the
toString evaluations that may be going on. That is - your call to
"canStepOver" may return false if a background/implicit toString()
evaluation is taking place.

One way to avoid these problems is to use an event filter rather than an
event listener (depending on what you want to achieve). By using an event
filter, you can intercept events, and change the state of the debug model
without effecting other listeners (since they will not be notified of
filtered events). For example, this is the way the "Step Into Selection"
actions works in the Java debugger. It performs a series of "step into"
actions to step into the selected method. (See the code for more details).

Hope this helps.

Darin



|---------+------------------------------->
|         |           Philipp.Bouillon@t-o|
|         |           nline.de            |
|         |           Sent by:            |
|         |           jdt-debug-dev-admin@|
|         |           eclipse.org         |
|         |                               |
|         |                               |
|         |           04/15/2003 07:46 AM |
|         |           Please respond to   |
|         |           jdt-debug-dev       |
|         |                               |
|---------+------------------------------->
  >---------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                             |
  |       To:       jdt-debug-dev@xxxxxxxxxxx                                                                                                   |
  |       cc:                                                                                                                                   |
  |       Subject:  [jdt-debug-dev] Weird stepping problem                                                                                      |
  |                                                                                                                                             |
  >---------------------------------------------------------------------------------------------------------------------------------------------|




Hi,

consider the following method:

public void testBuffer() {
    StringBuffer buf = new StringBuffer();
    for (int i = 0; i < 60; i++) {
        buf.append("foobar");
    }
    int x = 1;
}

I am tyring to programmatically step through this program, so I have
set a MethodEntry breakpoint at testBuffer and a LineBreakpoint at "int
x = 1;". Then, I registered a IJavaBreakpointListener with the
JDIDebugModel. This listener installs a IDebugEventSetListener upon
reaching the first breakpoint and removes the IDebugEventSetListener
upon reaching the second breakpoint.
The IDebugEventSetListener does the following (pseudo code):

for all debug events:
  get IJavaThread from event.getSource
    if thread is suspended (step.end) {
      if thread canStepOver {
        thread.stepOver();
      } else {
        thread.resume();
    } else {
     thread.resume();
    }

So basically, I perform a step-over all lines in the code, right?
The problem is, that the above code works perfectly under Windows XP
using Eclipse 2.1 and Sun Java SDK 1.4.1_02.
However, if I run the code _twice_ under Linux (Debian) with Eclipse
2.1 and Sun Java SDK 1.4.1_02, it stops somewhere between two steps.
Note that I can run this code as often as I like under Windows, but
Linux does not complete the second run.
Another note: If I do not use a StringBuffer in the "testBuffer"
method, it works well (so far, StringBuffer is the only class which
showed this strange behaviour).

Now, did _I_ miss anything (as I have not been developing with/for
exclipse for too long, I am not sure if I picked the right approach) or
could this indicate a bug in Eclipse or the JDK?
Am I allowed to use thread.{stepInto/stepOver/resume/terminate...}
commands in the IDebugSetEventListener, or does that produce thread
problems?

Thanks for your time and any suggestions,
Philipp Bouillon
_______________________________________________
jdt-debug-dev mailing list
jdt-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev