[Github-comments] [geany/geany-plugins] How to debug a multithread application [ Debugger / gdb ] (#1069)

[nomadbyte]

@avafinger: Thanks for the quick turn around with the testing. I'm glad that your results seem to show that the mentioned issues are gone.

If I understand it correctly, your assumption about disregarding the breakpoints in peer threads is not consistent with the GDB All Stop mode.

Just to reiterate this, in GDB All Stop mode:

- when hitting a breakpoint, GDB will halt all running threads and switch to the context of the thread that has hit the breakpoint 
- stepping/continuing from the Stopped state will resume **all** concurrent threads
- in the absence of subsequent breakpoints in the running threads, GDB will maintain the currently selected thread context
- if a breakpoint is hit by a concurrent thread, GDB will halt all running threads and switch to that thread's context

Not sure how this works for your practical cases, but this GDB behavior does make sense, especially when threads do not share the task-function. When such threads hit breakpoints in their task-function code, it's reasonable -- and convenient too -- to expect thread context to switch to that thread.

As for how to achieve your desired thread context switching (or rather non-switching) behavior -- one simple and common way is by making the breakpoints **conditional** on the intended thread-id (or some surrogate). In your example, the watched variable *i* could be used in the shared breakpoint condition (e.g. i==0, for making the breakpoint effective only for thread 0). The condition can be added in the Breakpoints pane.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1069#issuecomment-1088119436
You are receiving this because you are subscribed to this thread.

Message ID: <geany/geany-plugins/issues/1069/1088119436 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20220404/2d9e6253/attachment.htm>