GDB multithreaded Debugging __gdb

gdb multithreaded Debugging

First, let me introduce the basic commands of GDB multithreaded debugging.

Info Threads Displays all currently available threads, each thread will have an ID assigned to it by GDB, and this ID will be used to manipulate the thread later. The front with * is the currently debugged thread.

The thread ID Toggles threads that are currently being debugged to a specified ID.

Break thread_test.c:123 Thread all set a breakpoint on the corresponding line in all threads

The thread apply ID1 ID2 command lets one or more threads perform the GDB command command.

The thread apply all command lets all debugged threads execute GDB command commands.

set scheduler-locking off|on|step estimates that anyone who has actually used multithreaded debugging can find that other threads are executing concurrently when using the step or Continue command to debug the currently debugged thread. How to only let the debugger execute it. This requirement can be achieved through this command. Off does not lock any threads, that is, all threads execute, which is the default value. On only the currently debugged program will execute. Step when stepping, in addition to next a function of the case (people familiar with the situation may know that this is actually a set of breakpoints and then continue behavior), only when the line will execute.

GDB has the following support for debugging multithreaded routines: Thread-generated notifications: GDB gives hints when new threads are generated

(GDB) R
Starting program:/root/thread
[New Thread 1073951360 (LWP 12900)]
[New Thread 1082342592 (LWP 12907)]---The following three generated threads
[New Thread 1090731072 (LWP 12908)]
[New thread 1099119552 (LWP 12909)] View threads: Use the info threads to view the running threads.

(GDB) Info threads
4 Thread 1099119552 (LWP 12940) 0xffffe002 in?? ()
3 Thread 1090731072 (LWP 12939) 0xffffe002 in?? ()
2 Thread 1082342592 (LWP 12938) 0xffffe002 in?? ()
* 1 Thread 1073951360 (LWP 12931) Main (argc=1, argv=0xbfffda04) at thread.c:21
(GDB)

Note that the blue text at the beginning of the line is the thread number assigned to GDB, which is used when switching threads, not the green numbers that are marked above.

In addition, the red asterisk at the beginning of the line identifies the currently active thread-switching thread: Switching using thread threadnumber, threadnumber for the thread number mentioned above. The following example shows that the active thread is switched from 1 to 4.

(GDB) Info threads
4 Thread 1099119552 (LWP 12940) 0xffffe002 in?? ()
3 Thread 1090731072 (LWP 12939) 0xffffe002 in?? ()
2 Thread 1082342592 (LWP 12938) 0xffffe002 in?? ()
* 1 Thread 1073951360 (LWP 12931) Main (argc=1, argv=0xbfffda04) at thread.c:21
(GDB) Thread 4
[Switching to thread 4 (thread 1099119552 (LWP 12940))] #0 0xffffe002 in?? ()
(GDB) Info threads
* 4 Thread 1099119552 (LWP 12940) 0xffffe002 in?? ()
3 Thread 1090731072 (LWP 12939) 0xffffe002 in?? ()
2 Thread 1082342592 (LWP 12938) 0xffffe002 in?? ()
1 Thread 1073951360 (LWP 12931) Main (argc=1, argv=0xbfffda04) at thread.c:21
(GDB)

The back is directly in your thread function to set breakpoints, and then continue to that breakpoint, in general, multithreading, because it is running at the same time, it is best to set scheduler-locking on

In this case, only the current thread is debugged

reproduced from : http://www.cnblogs.com/xuxm2007/archive/2011/04/01/2002162.html