Community
Participate
Working Groups
When debugging a multi-threaded application using gdbserver and stepping over "pthread_create" the newly created thread causes the change of selection from the stepping thread to the "target" element. This doesn't happen when debugging the same application locally. The difference is the order in which the "running", "thread-created" and "stopped" events appear in GDB. In case of the local session the order is 1. running 2. thread-created 3. stopped For remote sessions 1. running 2. stopped 3. thread-created
Created attachment 233282 [details] Test project. Attaching a test case.
Currently the threads are displayed in the Debug view in the same order as they are fetched from GDB: the first thread appears at the bottom of the list and each newly created thread is added to the top of the list. Reversing this order makes the problem disappear. Moreover, only the first thread remains expanded when stepping, while currently the top thread gets expanded too. Interestingly the threads are sorted in "MIThreadListIdsInfo" but not in "MIThreadInfoInfo". I have pushed a simple patch that adds sorting to "MIThreadInfoInfo" to Gerrit - https://git.eclipse.org/r/#/c/14415/. Marc, could you please review?
(In reply to comment #2) > Currently the threads are displayed in the Debug view in the same order as > they are fetched from GDB: the first thread appears at the bottom of the > list and each newly created thread is added to the top of the list. > Reversing this order makes the problem disappear. I can see the problem too. Making this reverse order change is kind of a big deal though, as it changes the behaviour quite visibly for the user. If there was a simpler solution that kept the same order, that would be easiest. If, on the other hand, sorting the threads is something we feel is better for the user, then we can go that way, but I don't think we should make this decision without considering the impacts. Do you actually find the proposed solution better, if we ignore the selection bug?
(In reply to comment #3) > (In reply to comment #2) > > Currently the threads are displayed in the Debug view in the same order as > > they are fetched from GDB: the first thread appears at the bottom of the > > list and each newly created thread is added to the top of the list. > > Reversing this order makes the problem disappear. > > I can see the problem too. > > Making this reverse order change is kind of a big deal though, as it changes > the behaviour quite visibly for the user. > > If there was a simpler solution that kept the same order, that would be > easiest. If, on the other hand, sorting the threads is something we feel is > better for the user, then we can go that way, but I don't think we should > make this decision without considering the impacts. > > Do you actually find the proposed solution better, if we ignore the > selection bug? I do think that displaying the threads in order of their appearance is better. The other side effect of this patch is the newly created threads are not expanded, the view is more compact and no unnecessary editor tabs are opened. Also, as I already mentioned, the debugger versions that use "-thread-list-ids" are sorted. There is a chance that it's a bug in GDB, that the "thread-created" event should appear before the "stopped" event as it does for the local version.
(In reply to comment #4) > I do think that displaying the threads in order of their appearance is > better. The other side effect of this patch is the newly created threads are > not expanded, the view is more compact and no unnecessary editor tabs are > opened. > Also, as I already mentioned, the debugger versions that use > "-thread-list-ids" are sorted. Doh! Looks like the reverse order of threads we see with newer GDB version is a bug in CDT, as described in Bug 225996. Ok then, based on that, let's go with the ordering with new threads at the bottom. To track this better can we open a new bug about the ordering? I find the current bug to be a side-effect only of the real change you are making. Also, what do you think about sorting the threads in the services instead of the MI output files? It sounds more future-proof to me.
(In reply to comment #5) > Also, what do you think about sorting the threads in the services instead of > the MI output files? It sounds more future-proof to me. My first intention was to do the sorting in the services and it is the right thing to do. The problem is "MIThreadInfoInfo" is used in so many places it is hard to track whether we really need to do the sorting or not. I also did it in the same way as it is done for MIThreadListIds.
*** Bug 423898 has been marked as a duplicate of this bug. ***
Mikhail, should we commit the fix you posted for this bug?
(In reply to Marc Khouzam from comment #8) > Mikhail, should we commit the fix you posted for this bug? We haven't agreed on where to do the sorting. If you are OK with my patch then yes.
(In reply to Mikhail Khodjaiants from comment #9) > (In reply to Marc Khouzam from comment #8) > > Mikhail, should we commit the fix you posted for this bug? > > We haven't agreed on where to do the sorting. If you are OK with my patch > then yes. I'm ok with it. We've delayed this long enough :)
(In reply to Marc Khouzam from comment #10) > (In reply to Mikhail Khodjaiants from comment #9) > > (In reply to Marc Khouzam from comment #8) > > > Mikhail, should we commit the fix you posted for this bug? > > > > We haven't agreed on where to do the sorting. If you are OK with my patch > > then yes. > > I'm ok with it. We've delayed this long enough :) Thanks. I'll update the patch in Gerrit and apply it.
Checked in. Thanks Marc.
