[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-debug-dev] Weird stepping problem
|
This definitely looks wrong. Can you please file a bug report for this issue?
Thanks,
- Jared
On Tuesday 15 April 2003 10:12 am, Philipp.Bouillon@xxxxxxxxxxx wrote:
> 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
> >
> _______________________________________________
> jdt-debug-dev mailing list
> jdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-debug-dev
>
