[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-debug-dev] Thread mix-up when debuggingmulti-threaded programs
|
Hi Mikhail,
Here are some questions and findings regarding the thread mix-up problem
when debugging multi-threaded programs:
A question; if you use CDT 3.0.2 with Eclipse 3.2, will the new
asynchronous org.eclipse.debug framework be used or will the old
synchronous one be used instead?
I have noticed that when you select a new thread in the Debug view,
there is no MI thread-select command issued in the GDB console. Is this
wrong or will CDT change to the new thread as soon as a step operation
or similar is issued on it?
I have noticed that
org.eclipse.debug.internal.ui.viewers.update.ThreadEventHandler.handleResume(DebugEvent)
will remove the thread corresponding to the resume event from its list
of suspended threads and then take the next thread in its list of
suspended threads and call fireDeltaUpdatingTopFrame() on it, which will
make the topmost frame of that thread selected if it has one. However,
handleResume(DebugEvent) is not called for all threads, which will make
fireDeltaUpdatingTopFrame() change the selection to some other thread's
topmost frame when singlestepping a newly selected thread. This seems
wrong to me. In many systems, all threads in the program are suspended
when a breakpoint is hit or a singlestep is completed, and all threads
are resumed during the course of a singlestep operation. Are some resume
events lost on the way from CDT to org.eclipse.debug or doesn't the new
framework support this kind of systems?
I have also noticed that
org.eclipse.debug.internal.ui.viewers.update.EventHandlerModelProxy.dispatchResume()
will only call ThreadEventHandler.handleResume(DebugEvent) if the event
is not a "step start" event, in which case it will start a one-shot
PendingSuspendTask timer that will trigger in 500 ms and then call
ThreadEventHandler.handleSuspendTimeout(). However, if it does not
timeout, nothing seems to be done. That seems to explain why this
problem doesn't show up when debugging org.eclipse.debug and CDT and
singlestepping the event handling code. Also, if I change the
PendingSuspendTask timer to trigger after 1 ms the problem shows up very
rarely (however, it has showed up two times...).
This is as far as I can get with this problem. Debugging the new
asynchronous org.eclipse.debug framework is extremely difficult. I hope
my ramblings are useful for any further investigations.
There are several bug reports on the new asynchronous org.eclipse.debug
framework. Is it wise for CDT 3.1 to switch to it at this point or would
we have a more stable CDT 3.1 debug environment by using the old
synchronous model?
Kind regards,
Stefan
Mikhail Khodjaiants wrote:
Hi Stefan,
Thank you for looking at it. I'll check why this problem doesn't occur
with CDT 3.0.2, I don't recall if we have made any serious changes in
this area. And it is very difficult to debug it - the new asynchronous
framework for the views have many layers and runs all request in
separate jobs.
Best regards,
Mikhail
-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx
[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan Bylund
Sent: 30 August 2006 13:51
To: CDT Debug developers list
Subject: Re: [cdt-debug-dev] Thread mix-up when debuggingmulti-threaded
programs
Hi Mikhail,
I noticed that several thread-related bugs has been fixed in
org.eclipse.debug in the Eclipse 3.2.1 maintenance branch. So I tried
the M20060828-1036 build of Eclipse 3.2.1 but unfortunately this problem
still exists. I also tried using CDT 3.0.2 with Eclipse
3.2.1-M20060828-1036 and now it works, i.e. the thread switching problem
is gone! This leads me to believe that this bug is really in CDT 3.1 and
not in org.eclipse.debug in Eclipse 3.2. A colleague of mine is
debugging CDT to try to find this problem but without luck so for...
Any help or input on this problem would be much appreciated.
Kind regards,
Stefan
Mikhail Khodjaiants wrote:
Hi Stefan,
I have spent some time trying to figure out why this is happening. The
CDT sets the current thread correctly, but it seems that the Debug view
remembers the previous expansion state and restores it replacing the
correct one. The cause is hidden deep in the new implementation of the
Debug platform views, I haven't found the solution yet.
Regards,
Mikhail Khodjaiants
ARM Ltd.
-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx
[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan Bylund
Sent: 25 August 2006 21:38
To: cdt-debug-dev@xxxxxxxxxxx
Subject: [cdt-debug-dev] Thread mix-up when debugging multi-threaded
programs
Hi,
I recently switched from Eclipse 3.1.2 / CDT 3.0.2 / GDB 6.3 to Eclipse
3.2 / CDT 3.1 / GDB 6.3 and discovered a very annoying bug in the CDT
Debug view when debugging multi-threaded programs. When you select the
topmost frame in another thread in the Debug view, that frame will be
selected. However, when trying to singlestep the newly selected thread,
the topmost frame of the previous thread is erroneously selected again.
By selecting, the topmost frame of the intended thread again, you will
notice that the singlestep operation really happened and you can from
here on singlestep in the new thread without being switched back.
However, when selecting a new thread again, the same problem happens
again and you have to reselect the new thread to be able to continue.
There seems to be some inconstistency about which thread is the current
between the Debug view and the CDT debug model or between different
parts of the CDT debug model. This bug did not exist in Eclipse 3.1.2 /
CDT 3.0.2.
I have searched the Eclipse bug database for any bugs about this and
found the bug 151253 "Singlestepping a multi-thread program to fast
results in unexpected behavior" which I thought could be related to
this problem. Bug 151253 has been fixed in the CDT 3.1.1 branch so I
downloaded the I200608210800 nightly build of CDT 3.1.1 but
unfortunately the thread switching problem problem still exists.
Is this a known problem with CDT 3.1? Otherwise, I can file a bug
report.
Regards,
Stefan
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev