GDB multithreaded debugging

Deadlock: A situation in which two or more threads in the executing program are permanently blocked (waiting), and each thread waits for

Resources that other threads occupy and block. For example, if thread a locks record 1 and waits for record 2, and thread B locks record 2 and waits for record 1, a deadlock occurs for two threads. GdB Debug Deadlock method: GdB attach Pidthread apply all BT find _lll_lock_wait lock wait place. Then find out which thread locked the lock. For example: see which thread owns the mutex (gdb) Print accounta_mutex$1 = {__m_reserved = 2, __m_count = 0, __m_owner = 0x2527,__m_kind = 0, __m_lock= {__status = 1, __spinlock = 0}} (gdb) Print 0x2527$2 = 9511 (gdb) Print accountb_mutex$3 = {__m_reserved = 2, __m_count = 0, __m_owner = 0x2529,__m_kind = 0, __m_lock = {__status = 1, __spinlock = 0}} (gdb) Print 0x2529$4 = 9513 (gdb) from the above command, we can see that Acconta_mutex is locked by thread 5 (LWP 9511) (owned), while Accontb_mutex is a thread 3 (LWP 9513) locking (owned).

Find out where the deadlock is, and check the code accordingly. Deadlocks are mostly caused by cross-use of locks, and methods for resolving deadlocks are often:The method of orderly resource allocation

is an algorithm to prevent deadlocks in the operating system, the algorithm resources according to a rule system of all resources in a uniform number (such as printer 1, tape drive 2, disk 3, etc.), the application must be in ascending order. The system requires the application process:  1, all resources that must be used and belong to the same category must be completed one time,  2, in the application of different types of resources, the number of various types of equipment must be applied sequentially. For example: Process PA, the order of resources is R1,R2            , process PB, the order of using resources is R2,R1 , if dynamic allocation is possible to form a loop condition, resulting in deadlock.  using the ordered resource allocation method: The number of R1 is numbered as 1,R2 2;  PA: The order of application should be: R1,R2  PB: The order of application should be: R1,R2  

Banker AlgorithmWe can think of the operating system as bankers, and the operating system manages resources equal to the money that bankers manage, and the process asks the operating system to allocate resources equivalent to users lending to bankers. In order to ensure the safety of funds, bankers rule: (1) When a customer's maximum demand for funds does not exceed the bank's existing funds to be able to accept the customer, (2) the customer can be instalment loans, but the total number of loans cannot exceed the maximum demand, (3) when the banker's existing funds can not meet the customer's remaining loan amount Loans to customers can be deferred, but always allow customers to get loans in limited time, (4) when the customer gets all the money they need, Must be able to return all the funds in a limited time. The operating system allocates resources for the process in accordance with rules established by bankers, and when the process first requests resources, it tests the maximum resource requirements for the process, and if the system's existing resources can meet its maximum demand, allocate resources according to the current amount of requests, or postpone the allocation. When the process continues to request resources in execution, first test the process for the number of resources this request exceeds the total amount remaining for that resource. If the resource is not allocated, the resource will be allocated according to the current application amount, otherwise the allocation will be deferred. Reference: http://blog.csdn.net/wqlyqy/article/details/9195625

/** Deadlock Debug 1)-G parameter 2) Attach 3) Info threads 4) thread + number switch to the corresponding thread or thread apply all BT set breakpoints all*/#include<stdio.h>#include<pthread.h>#include<unistd.h>void*workthread (void*Arg)    {pthread_mutex_t Mutex; Pthread_mutex_init (&mutex,0); Usleep ( +* +); fprintf (stderr,"Timeout We'll start dead lock\n"); Pthread_mutex_lock (&mutex); Pthread_mutex_lock (&mutex);}void*alivethread (void*Arg) {     while(true) {Usleep ( +* +); }}intMainintargcChar*argv[])    {pthread_t alivepid; Pthread_create (&alivepid,0, Alivethread,0);    pthread_t Deadpid; Pthread_create (&deadpid,0, Workthread,0); void*retval =0; Pthread_join (Deadpid,&retval); void*retval2 =0; Pthread_join (Alivepid,&retval2); return 0;}

2. Compile and run LOCK.C
[Email protected] ~]# gcc-g lock.c-pthread
[Email protected] ~]#./a.out
Timeout We'll start dead lock

(Program hangs)

3. Find the Process ID

[Email protected] ~]# ps-e | grep a.out

12826 PTS/3 00:00:00 a.out//process ID is 12826

GDB Multi-threaded DEBUG command:

(GDB) Info threads
Displays all threads currently available for debugging, each of which has a GDB-assigned ID, which is used when the thread is later manipulated.
Previous * is the thread that is currently being debugged.

(GDB) Thread ID
Toggles the thread of the currently debugged thread to the specified ID.

(GDB) thread apply ID1 ID2 command
Have one or more threads execute GDB command commands.
(GDB) thread apply all command
Let all the debugged threads execute the GDB command.

(GDB) Set scheduler-locking off|on|step
It is estimated that people who have actually used multi-threaded debugging can find that when using the step or the continue command to debug the currently debugged thread, the other threads are executed simultaneously, how to only let the debug program execute it? This requirement can be achieved with this command.
Off does not lock any threads, that is, all threads are executed, which is the default value.
On only the currently debugged program will execute.
Step in a single step, in addition to the case of next over a function (the person familiar with the situation may know that this is actually a set breakpoint and then continue behavior), only when the front-thread will execute.

displaying thread stack information
(GDB) BT
See all the call stacks

(GDB) F 3
Call Box Hierarchy

(GDB) I locals
Show all variables for all current call stacks

4. Start the GDB attach process

[Email protected] ~]# gdb a.out 12826
GNU gdb (GDB) CentOS (7.0.1-45.el5.centos)
Copyright (C) Software Foundation, Inc.
License gplv3+: GNU GPL version 3 or later This was free software:you was free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "Show copying"
and "Show warranty" for details.
This GDB is configured as "I386-redhat-linux-gnu".
For bugs reporting instructions, please see:
Reading symbols From/root/a.out...done.
Attaching to Program:/root/a.out, Process 12826
Reading symbols from/lib/libpthread.so.0 ... (No debugging symbols found) ... done.
[Thread debugging using libthread_db enabled]
[New Thread 0xb7524b90 (LWP 12828)]
[New Thread 0xb7f25b90 (LWP 12827)]
Loaded symbols for/lib/libpthread.so.0
Reading symbols from/lib/libc.so.6 ... (No debugging symbols found) ... done.
Loaded symbols for/lib/libc.so.6
Reading symbols from/lib/ld-linux.so.2 ... (No debugging symbols found) ... done.
Loaded symbols for/lib/ld-linux.so.2
0x00502402 in __kernel_vsyscall ()
(GDB)Info threads//Display all thread information
3 Thread 0xb7f25b90 (LWP 12827) 0x00502402 in __kernel_vsyscall ()
2 Thread 0xb7524b90 (LWP 12828) 0x00502402 in __kernel_vsyscall ()
* 1 Thread 0xb7f266c0 (LWP 12826) 0x00502402 in __kernel_vsyscall ()
(GDB)Thread 2//Jump to 2nd thread
[Switching to Thread 2 (thread 0xb7524b90 (LWP 12828)]) #0 0x00502402 in __kernel_vsyscall ()
(GDB)BT//View thread 2 stack, can find that thread blocked on line 17th of LOCK.C
#0 0x00502402 in __kernel_vsyscall ()
#1 0x0072e839 in __lll_lock_wait () from/lib/libpthread.so.0
#2 0x00729e9f in _l_lock_885 () from/lib/libpthread.so.0
#3 0x00729d66 in Pthread_mutex_lock () from/lib/libpthread.so.0
#4 0x080485b4 in Work_thread (arg=0x0) at lock.c:17
#5 0x00727912 in Start_thread () from/lib/libpthread.so.0
#6 0x0066660e in Clone () from/lib/libc.so.6
(GDB)


Reference from http://blog.csdn.net/openxmpp/article/details/8615000

Another article:

After introducing core dump, let's look at how to use core dump in multithreaded debugging.

Use the KILL command to produce a core dump file:

kill-11 PID

This is not the process of killing it? Yes, but if you kill it with the signal 11, it will cause the process to generate a segmentation Fault, which, if you don't disable core dump, causes a core dump. Then you get a core file that contains the deadlock, the memory image of the process, including the tangled lingering, death thereby generating the deadlock of the two, maybe a few, threads, stacks.

Do you know what to do now? Open the core file with GDB, and then

Thread Apply all BT

GDB will play all the threads of the stack, if you find that there are a few stacks parked in pthread_wait or similar calls, it is generally possible to conclude that they are a few ernvqingchang, delaying the whole process.

Let me give you a simple example (using the C++11 thread library for the code as simple as possible)

#include <iostream>#include<thread>#include<mutex>#include<chrono>using namespaceStd;mutex m1,m2;voidfunc_2 () {m2.Lock(); cout<<"About to Dead_lock"<<Endl; M1.Lock(); }voidFunc_1 () {M1.Lock(); Chrono::milliseconds Dura ( +);//delay to trigger Dead_lockthis_thread::sleep_for (Dura); M2.Lock(); }intmain () {thread T1 (func_1);        Thread T2 (func_2);    T1.join ();    T2.join (); return 0;}

Compiling code

$> g++-wall-std=c++11 dead_lock_demo.cpp-o dead_lock_demo-g-pthread

Run the program, the Discovery program prints out "about to Dead_lock" will not move, now we use GDB to debug. Note that GDB has a version higher than 7.0, and it is not possible to debug multithreading before using gdb6.3.

Before this, you need to generate a core dump file:

$> Ps-aux | grep Dead_lock_demo

Locate the Dead_lock_demo thread number, and then:

$> kill-11 PID

The core dump file is generated and the name on my system is the core

Then debug:

$> GDB Dead_lock_demo Core

$> thread apply all BT

Here's a look at the actual process:

It can be seen that two threads are blocked on wait, and in which line of code it is easy to navigate to the location where the deadlock is generated.

Reference: http://www.cnblogs.com/zhuyp1015/p/3618863.html

GDB multithreaded debugging