[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-debug-dev] Thread mix-upwhen debuggingmulti-threaded programs
|
Hi Stefan,
Sorry that I didn't reply to you. But I haven't settled in yet. I have
been moving from one hotel/guest house to another and the one I was
staying during the weekend surprisingly didn't have Internet access. And
I was at a training for the last two days. And I will be busy moving to
my new apartment for the most of this week. But I am planning to look at
it as soon as I can.
Regards,
Mikhail
-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx
[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan Bylund
Sent: 06 September 2006 17:55
To: CDT Debug developers list
Subject: Re: [cdt-debug-dev] Thread mix-upwhen debuggingmulti-threaded
programs
Hi Mikhail,
Have you had any luck with this problem?
Kind regards,
Stefan
Mikhail Khodjaiants wrote:
>Hi Stefan,
>
>Thanks for investigating the problem. Indeed, it is very difficult to
>debug the new framework. You can turn of the tracing of the debug
>plugins, it may help to see what is happening.
>Here are the answers to some of your questions. I'll take a better look
>at the problem during this weekend using your tips.
>
>
>>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?
>>
>>
>
>The asynchronous debug framework is a part of Eclipse 3.2 and it is
>used by the platform views regardless of the version of CDT.
>
>
>
>>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?
>
>The CDT will set the new thread as a part of the step operation.
>
>
>
>>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?
>
>We had no choice. Actually, we didn't switch to it, the platform did. I
>only redesigned the Modules view, which is now based on
>AsynchronousTreeViewer.
>
>Best regards,
>Mikhail
>
>-----Original Message-----
>From: cdt-debug-dev-bounces@xxxxxxxxxxx
>[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan Bylund
>Sent: 31 August 2006 18:13
>To: CDT Debug developers list
>Subject: Re: [cdt-debug-dev] Thread mix-upwhen 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.handleR
>e
>sume(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.dis
>p
>atchResume()
>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
>>
>>
>>
>>
>
>_______________________________________________
>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
-- The 2006 ARM Developers' Conference, October 3-5, Santa Clara, US
Join ARM and its technology and tools Partners from around the world at the only industry event for developers of ARM Powered(R) solutions.
http://www.arm.com/developersconference/
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.
