If I want to debug a segment of code in my program, and the code will
run in two threads simultaneously.
When I set a breakpoint in the code, and run the program step by step
from the breakpoint in the code, the program often receive the signal
SIGTRAP.
At first I thought after a thread ran to the breakpoint and stop, and
the other thread would run to the breakpoint and stop too, so it would
make confusing.So I set the breakpoint with tbreak. But the program
still received the signal SIGTRAP when debugged.
How to debug such code with gdb?

On 2005-05-09, Zheng Da <zhengda1936@sina.com> wrote:
> If I want to debug a segment of code in my program, and the code will
> run in two threads simultaneously.
> When I set a breakpoint in the code, and run the program step by step
> from the breakpoint in the code, the program often receive the signal
> SIGTRAP.
> At first I thought after a thread ran to the breakpoint and stop, and
> the other thread would run to the breakpoint and stop too, so it would
> make confusing.So I set the breakpoint with tbreak. But the program
> still received the signal SIGTRAP when debugged.
> How to debug such code with gdb?
>

I'm not sure if this would help, but I found that using 'thread apply'
command helps a lot. So, the first thing to do is to find out thread id.

gdb> info threads

The thread marked with '*' is the current thread. So pickup the id
(let's say it is 10). Now, to make sure that when I do 'next' no other
thread hits current break point, I delete it. Now I say

gdb> thread apply 10 next

This does 'next' only for thread with id 10.


-- 
Minds, like parachutes, function best when open

It doesn't work. There is still the signal