Sand-breaking pot
Open source GDB is widely used in Linux, OSX, UNIX and various embedded systems (such as mobile phones), this time it brings us a surprise.
The pain of multi-threaded debugging
Debuggers (such as VS2008 and older gdb) tend to support only all-stop mode, when debugging multithreaded programs, if a thread breaks on a breakpoint, your debugger will let the entire program freeze until you continue the thread and other threads in the program will continue to run. This restriction prevents the program being debugged from running as it does in the real world-when a thread breaks on a breakpoint and other threads run in parallel.
The Non-stop model introduced by GDBv7.0 makes this problem solved. In this mode,
- When one or more threads break on one breakpoint, other threads still run in parallel
- You can select a broken thread and let it continue to run
Let's imagine that with this feature
- When other threads break on a breakpoint, the timer thread in the program can run normally, thus avoiding the need to timeout
- When other threads break on a breakpoint, the watchdog thread in the program can run normally, preventing the embedded hardware from restarting when the system crashes
- You can control the order in which multiple threads run, thus reproducing the deadlock scene. Since GDB can be used to drive debugging with a Python script, it is theoretically possible to test the program automatically in a different thread run order.
Therefore, the Non-stop mode is naturally a multi-threaded debugging "must kill skill". The Linux version released after the second half of 2009 years has a GDBv7.0 version. Very curious, do not know whether the VS2010 also support similar debug mode.
Demonstrates GDB's non-stop mode
Let the broken sand pot with a C + + applet in Ubuntu Linux 09.10 demo This must kill skill. Although my demo uses the command line version of GDB, if you like the graphical debugger, Eclipse2009 May version can easily call this feature, details see eclipse See http://live.eclipse.org/node/723
1. Compile the following program nonstop
1//GDB Non-stop mode Demo
2//Build instruction:g++-g-o nonstop Nonstop.cpp-lboost_thread
3
4 #include <iostream>
5 #include <boost/thread/thread.hpp>
6
7 struct OP
8 {
9 OP (int id): m_id (ID) {}
10
One void operator () ()
12 {
Std::cout << m_id << "Begin" << Std::endl;
Std::cout << m_id << "End" << Std::endl;
15}
16
m_id int;
18};
19
int main (int argc, char * * argv)
21 {
Boost::thread T1 (OP (1)), T2 (OP (2)), T3 (OP (3));
T1.join (); T2.join (); T3.join ();
return 0;
25}
26
2. Add 3 lines to ~/.gdbinit to open Non-stop mode
Set Target-async 1
Set Pagination off
Set Non-stop on
3. Start GDB, set breakpoints, run. You can see that the main thread 1 is that the running,3 child thread is broken on the breakpoint, not just one child thread on the breakpoint.
~/devroot/nonstop$ gdb./nonstop
GNU gdb (GDB) 7.0-ubuntu
Reading symbols From/home/frankwu/devroot/nonstop/nonstop...done.
(GDB) Break 14
Breakpoint 1 at 0x402058:file Nonstop.cpp, line 14.
(GDB) Break 24
Breakpoint 3 at 0x401805:file Nonstop.cpp, line 24.
(GDB) Run
Starting program:/home/frankwu/devroot/nonstop/nonstop
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff6c89910 (LWP 2762)]
[New Thread 0x7ffff6488910 (LWP 2763)]
1 begin
Breakpoint 1, Op::operator () (this=0x605118) at nonstop.cpp:14
Std::cout << m_id << "End" << Std::endl;
2 begin
Breakpoint 1, Op::operator () (this=0x605388) at nonstop.cpp:14
Std::cout << m_id << "End" << Std::endl;
[New Thread 0x7ffff5c87910 (LWP 2764)]
3 begin
Breakpoint 1, Op::operator () (this=0x605618) at nonstop.cpp:14
Std::cout << m_id << "End" << Std::endl;
(GDB) Info threads
4 Thread 0x7ffff5c87910 (LWP 2764) op::operator () (this=0x605618) at nonstop.cpp:14
3 Thread 0x7ffff6488910 (LWP 2763) op::operator () (this=0x605388) at nonstop.cpp:14
2 Thread 0x7ffff6c89910 (LWP 2762) op::operator () (this=0x605118) at nonstop.cpp:14
* 1 Thread 0x7ffff7fe3710 (LWP 2759) (running)
4. Let thread 3 continue to run, note I Gui the main thread 1 also continue, this is I found workaround, otherwise gdb can not cut back thread 1.
(GDB) thread apply 3 1 continue
Thread 3 (thread 0x7ffff6488910 (LWP 2763)):
Continuing.
Thread 1 (thread 0x7ffff7fe3710 (LWP 2759)):
Continuing.
Cannot execute this command while the selected thread is running.
2 End
[Thread 0x7ffff6488910 (LWP 2763) exited]
Warning:unknown thread 3.
Thread 1 (thread 0x7ffff7fe3710 (LWP 2759)):
Continuing.
Cannot execute this command while the selected thread is running.
(GDB) Info threads
4 Thread 0x7ffff5c87910 (LWP 2764) op::operator () (this=0x605618) at nonstop.cpp:14
2 Thread 0x7ffff6c89910 (LWP 2762) op::operator () (this=0x605118) at nonstop.cpp:14
* 1 Thread 0x7ffff7fe3710 (LWP 2759) (running)
5. Let the other two threads continue to run and end, the main thread is broken in line 24th, and finally ends.
(GDB) thread apply 4 2 1 continue
Thread 4 (thread 0x7ffff5c87910 (LWP 2764)):
Continuing.
Thread 2 (thread 0x7ffff6c89910 (LWP 2762)):
Continuing.
Thread 1 (thread 0x7ffff7fe3710 (LWP 2759)):
Continuing.
Cannot execute this command while the selected thread is running.
3 End
1 End
[Thread 0x7ffff5c87910 (LWP 2764) exited]
[Thread 0x7ffff6c89910 (LWP 2762) exited]
Breakpoint 3, Main (argc=1, argv=0x7fffffffe348) at nonstop.cpp:24
return 0;
(GDB) Continue
Thread 1 (thread 0x7ffff7fe3710 (LWP 2759)):
Continuing.
Program exited normally.Resources
Debugging with GDB
Reverse debugging, Multi-process and Non-stop debugging Come to the CDT
GDB's Non-stop mode
