[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-debug-dev] Weird stepping problem
|
Hi,
thanks for the advice on using the filter instead of the listener. It
works perfectly now. Thank you.
One thing that caught my eye when analyzing the code of
org.eclipse.jdt.internal.debug.ui.actions.StepIntoSelectionHandler
@filterDebugEvents, lines 159-162:
for (int k = 1; k < events.length; k++) { filtered[k-1]=
events[k]; return filtered;
}
isn't that supposed to be:
for (int k = 1; k < events.length; k++) { filtered[k-1]=
events[k];
}
return filtered;
Again: Thanks for the help! That saved my day!
Philipp Bouillon
>
> 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
>
>
>
>
> _______________________________________________
> jdt-debug-dev mailing list
> jdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev
>
