使用gdb定位线程死锁问题

最新推荐文章于 2023-04-19 17:21:18 发布
最新推荐文章于 2023-04-19 17:21:18 发布
阅读量2.1k 收藏 11
点赞数 1
分类专栏： C++ 文章标签： gdb 死锁 线程 coredump
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_26348877/article/details/100328541
版权

死锁概念

什么是死锁，简单地说死锁就是一种现象，比如说有A，B两个线程 ，mtx_a，mtx_b两个互斥量。如果线程A拥有mtx_a的同时，去竞争mtx_b，刚好线程B这时拥有mtx_b，去竞争mtx_a，这时两个线程想要竞争的资源刚好都被对方占用，且都等待对方释放资源，由此陷入了僵局，这就是线程死锁的一种现象。

 

死锁的例子

平常编写代码的过程中比较容易出现的死锁主要有下面这几种，每种情况我们写一个简单的例子把问题点暴露出来，当然还有其他的情况这里就不一一举例说明了。

1. 两个或两个以上的互斥锁，上锁顺序问题

/*
    两个线程，一个线程不停调用pushData,另一个线程不停调用popData。
    很容易出现死锁：pushData拥有mutex1，请求mutex2，同时popData拥有mutex2，请求mutex1。
*/
class dataPool
{
public:
    dataPool()=default;
    void pushData(const std::string& data)
	{
	    std::unique_lock<std::mutex> lck1(mutex1);
	    std::unique_lock<std::mutex> lck2(mutex2);
	    dataPool_.push_back(data);
	}
	void popData(const std::string& data)
	{
	    std::unique_lock<std::mutex> lck2(mutex2);
	    std::unique_lock<std::mutex> lck1(mutex1);
	    dataPool_.pop_front(data);
	}
private:
    std::mutex mutex1;
    std::mutex mutex2;
    std::list<std::string> dataPool_;
}

2. 嵌套锁

/*
    如果代码调用层次较深，不留意时很容易发生这种嵌套上锁的情况。
    pushData中对mutex_上锁，下面调用findData时又请求mutex_，必现死锁。
*/
class dataPool
{
public:
	dataPool()=default;
	void pushData(int code,const std::string& data)
	{
		std::unique_lock<std::mutex> lck(mutex_);
		if(!findData(code))
		{
			dataMap_[code]=data;
		}
	}
	bool findData(int code)
	{
		bool bRet=false;
		std::unique_lock<std::mutex> lck(mutex_);
		auto it=dataMap_.find(code);
		if(it!=dataMap_.end())
		{
			bRet=true;
		}
		return bRet;
	}
private:
	std::mutex mutex_;
	std::map<int code,std::string > dataMap_;
}


3. 忘记解锁

/*
    忘记解锁也是一种情况，不过如果使用c++11中的版本，在作用域范围外自动解锁则可避免这种情况，
    好比智能指针。
*/
class dataPool
{
public:
	dataPool()=default;
	void pushData(const std::string& data)
	{
		mutex_.lock();
		dataPool_.push_back(data);
		mutex_.unlock();
	}
	void popData(const std::string& data)
	{
		mutex_.lock();
		dataPool_.pop_front(data);
                //mutex_.unlock();
	}
private:
	std::mutex mutex_;
	std::list<std::string> dataPool_;
}

避免方法

1. 两个互斥量总是以相同的顺序上锁:总在互斥量B之前锁住互斥量B
2. 避免嵌套锁:不要尝试在一个线程里获取两次锁
3. 有lock必须在后面unlcok，或使用std::unique_lock进行包装

 

定位方法

如果还是不小心出现了死锁情况，我们就要学会定位。一种方法是通过日志去定位大概的死锁点，不过这种方法有时并不适用。这里我们主要介绍一下使用gdb调试的方法进行定位死锁问题。

下面这段代码加上主线程有三个线程，同时对数据区进行push和pop操作，操作中构造了死锁产生的条件以便复现死锁问题。

（如果gdb查看堆栈信息时有不显示代码行号的问题，就在编译进程时加上 -g 选项）

 

#include <iostream>
#include <vector>
#include <memory>
#include <mutex>
#include <thread>
#include <string.h>
#define POOL_MAX_LEN (100)
#define POOL_DATA_MAX_SIZE (1*1024*1024)
using sourceData = struct sourceData_
{
	char* data;
	int dataLen;
};
struct delSourceData
{
	void operator()(sourceData* delData)
	{
		if (delData->data)
		{
			delete delData->data;
			delData->data = nullptr;
		}
		if (delData)
		{
			delete delData;
			delData = nullptr;
		}
	}
};
class DataPool
{
public:
	DataPool() :dataPool(100),
		poolBegin_(0),
		poolEnd_(0),
		poolEmpty_(true),
		poolFull_(false)
	{
		for (int idx = 0; idx < POOL_MAX_LEN;++idx)
		{
			std::shared_ptr<sourceData> tmpData(new sourceData, delSourceData());
			tmpData->data = new char[POOL_DATA_MAX_SIZE];
			dataPool[idx] = tmpData;
		}
	}
	~DataPool() = default;
	void pushToPool(std::shared_ptr<sourceData> inputData)
	{
		std::unique_lock<std::mutex> lckOne(mutexOne_);
		std::unique_lock<std::mutex> lckTwo(mutexTwo_);
		if (!inputData->data&&!poolFull_)
		{
			dataPool[poolEnd_]->dataLen = inputData->dataLen;
			int copyLen = inputData->dataLen>POOL_DATA_MAX_SIZE ? POOL_DATA_MAX_SIZE :
				inputData->dataLen;
			memcpy(dataPool[poolEnd_]->data, inputData->data, copyLen);
			poolEnd_ = (poolEnd_ + 1) % POOL_MAX_LEN;
			poolEmpty_ = false;
			poolFull_ = poolEmpty_ == poolFull_ ? true : false;
		}
	}
	void popFromPool(std::shared_ptr<sourceData> outData)
	{
		std::unique_lock<std::mutex> lckTwo(mutexTwo_);
		std::unique_lock<std::mutex> lckOne(mutexOne_);
		if (poolEmpty_)
		{
			outData->dataLen = dataPool[poolBegin_]->dataLen;
			memcpy(outData->data, dataPool[poolBegin_]->data, outData->dataLen);
			poolBegin_ = (poolBegin_ + 1) % POOL_MAX_LEN;
			poolFull_ = false;
			poolEmpty_ = poolEmpty_ == poolFull_ ? true : false;
		}
	}
	bool poolFull()
	{
		return poolFull_;
	}
	bool poolEmpty()
	{
		return poolEmpty_;
	}
private:
	std::vector<std::shared_ptr<sourceData> > dataPool;
	std::mutex mutexOne_;
	std::mutex mutexTwo_;
	int poolBegin_;
	int poolEnd_;
	bool poolEmpty_;
	bool poolFull_;
};
class FetchData
{
public:
	FetchData() :pool_(std::make_shared<DataPool>())
	{

	}
	~FetchData() = default;
	void pushData()
	{
		while (true)
		{
			std::shared_ptr<sourceData> inputData(new sourceData, delSourceData());
			inputData->data = new char[POOL_DATA_MAX_SIZE];
			pool_->pushToPool(inputData);
		}
	}
	void popData()
	{
		while (true)
		{
			std::shared_ptr<sourceData> outData(new sourceData, delSourceData());
			outData->data = new char[POOL_DATA_MAX_SIZE];
			pool_->popFromPool(outData);
			std::cout << "easy to occur deadlock" << std::endl;
		}
	}
private:
	std::shared_ptr<DataPool> pool_;
};
int main()
{
	std::shared_ptr<FetchData> fetchData = std::make_shared<FetchData>();
	std::thread tOne(&FetchData::pushData, fetchData);
	std::thread tTwo(&FetchData::popData, fetchData);
	tOne.join();
	tTwo.join();
	std::cout << "over" << std::endl;

	return 0;
}

1. 编译完成后，运行之前要打开core dump开关
   ulimit -c unlimited

2. 运行程序
   [root@ia10k gdb]# ./a.out 
   only for a test
   only for a test

3. 查看进程id，使用kill命令产生core dump
   [root@ia10k gdb]# pidof a.out 
   21458
   [root@ia10k gdb]# kill -11 21458
   [root@ia10k gdb]# 
   # 这时可以看到进程已产生core dump
   [root@ia10k gdb]# ./a.out 
   only for a test
   only for a test
   Segmentation fault (core dumped)
   [root@ia10k gdb]# ls
   a.out  core.18734  deadlock.cpp
   [root@ia10k gdb]#  

4. gdb打开core文件
   [root@ia10k gdb]# gdb a.out core.18734

5. 打印所有线程的堆栈信息
(gdb) thread apply all bt

Thread 3 (Thread 0x7fdc50a40700 (LWP 18735)):
#0  0x00007fdc5799542d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
#1  0x00007fdc57990dcb in _L_lock_812 () from /usr/lib64/libpthread.so.0
#2  0x00007fdc57990c98 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0
#3  0x00000000004010dc in __gthread_mutex_lock (__mutex=0xeab098) at /usr/include/c++/4.8.2/x86_64-redhat-linux/bits/gthr-default.h:748
#4  0x000000000040141e in std::mutex::lock (this=0xeab098) at /usr/include/c++/4.8.2/mutex:134
#5  0x0000000000402575 in std::unique_lock<std::mutex>::lock (this=0x7fdc50a3fd80) at /usr/include/c++/4.8.2/mutex:511
#6  0x0000000000401f99 in std::unique_lock<std::mutex>::unique_lock (this=0x7fdc50a3fd80, __m=...) at /usr/include/c++/4.8.2/mutex:443
#7  0x000000000040183f in DataPool::pushToPool (this=0xeab058, inputData=std::shared_ptr (count 2, weak 0) 0x7fdc480008c0) at deadlock.cpp:53
#8  0x0000000000401c45 in FetchData::pushData (this=0xeab028) at deadlock.cpp:109
#9  0x0000000000405414 in std::_Mem_fn<void (FetchData::*)()>::_M_call<std::shared_ptr<FetchData>>(std::shared_ptr<FetchData>&&, void const volatile*) const (this=0xead6b0, 
    __ptr=<unknown type in /home/hls/demo/gdb/a.out, CU 0x0, DIE 0xbe6d>) at /usr/include/c++/4.8.2/functional:558
#10 0x00000000004053a8 in std::_Mem_fn<void (FetchData::*)()>::operator()<std::shared_ptr<FetchData>, , void>(std::shared_ptr<FetchData>&&) const (this=0xead6b0, 
    __object=<unknown type in /home/hls/demo/gdb/a.out, CU 0x0, DIE 0xbe6d>) at /usr/include/c++/4.8.2/functional:610
#11 0x0000000000405261 in std::_Bind_simple<std::_Mem_fn<void (FetchData::*)()> (std::shared_ptr<FetchData>)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0xead6a0)
    at /usr/include/c++/4.8.2/functional:1732
#12 0x00000000004050b1 in std::_Bind_simple<std::_Mem_fn<void (FetchData::*)()> (std::shared_ptr<FetchData>)>::operator()() (this=0xead6a0) at /usr/include/c++/4.8.2/functional:1720
#13 0x0000000000404f90 in std::thread::_Impl<std::_Bind_simple<std::_Mem_fn<void (FetchData::*)()> (std::shared_ptr<FetchData>)> >::_M_run() (this=0xead688)
    at /usr/include/c++/4.8.2/thread:115
#14 0x00007fdc577342b0 in ?? () from /usr/lib64/libstdc++.so.6
#15 0x00007fdc5798ee25 in start_thread () from /usr/lib64/libpthread.so.0
#16 0x00007fdc56e9c34d in clone () from /usr/lib64/libc.so.6

Thread 2 (Thread 0x7fdc5023f700 (LWP 18736)):
#0  0x00007fdc5799542d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
#1  0x00007fdc57990dcb in _L_lock_812 () from /usr/lib64/libpthread.so.0
#2  0x00007fdc57990c98 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0
#3  0x00000000004010dc in __gthread_mutex_lock (__mutex=0xeab070) at /usr/include/c++/4.8.2/x86_64-redhat-linux/bits/gthr-default.h:748
#4  0x000000000040141e in std::mutex::lock (this=0xeab070) at /usr/include/c++/4.8.2/mutex:134
#5  0x0000000000402575 in std::unique_lock<std::mutex>::lock (this=0x7fdc5023ed90) at /usr/include/c++/4.8.2/mutex:511
#6  0x0000000000401f99 in std::unique_lock<std::mutex>::unique_lock (this=0x7fdc5023ed90, __m=...) at /usr/include/c++/4.8.2/mutex:443
#7  0x00000000004019f1 in DataPool::popFromPool (this=0xeab058, outData=std::shared_ptr (count 2, weak 0) 0x7fdc400008c0) at deadlock.cpp:68
#8  0x0000000000401d07 in FetchData::popData (this=0xeab028) at deadlock.cpp:119
#9  0x0000000000405414 in std::_Mem_fn<void (FetchData::*)()>::_M_call<std::shared_ptr<FetchData>>(std::shared_ptr<FetchData>&&, void const volatile*) const (this=0xead960, 
    __ptr=<unknown type in /home/hls/demo/gdb/a.out, CU 0x0, DIE 0xbe6d>) at /usr/include/c++/4.8.2/functional:558
#10 0x00000000004053a8 in std::_Mem_fn<void (FetchData::*)()>::operator()<std::shared_ptr<FetchData>, , void>(std::shared_ptr<FetchData>&&) const (this=0xead960, 
    __object=<unknown type in /home/hls/demo/gdb/a.out, CU 0x0, DIE 0xbe6d>) at /usr/include/c++/4.8.2/functional:610
#11 0x0000000000405261 in std::_Bind_simple<std::_Mem_fn<void (FetchData::*)()> (std::shared_ptr<FetchData>)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0xead950)
---Type <return> to continue, or q <return> to quit---
    at /usr/include/c++/4.8.2/functional:1732
#12 0x00000000004050b1 in std::_Bind_simple<std::_Mem_fn<void (FetchData::*)()> (std::shared_ptr<FetchData>)>::operator()() (this=0xead950) at /usr/include/c++/4.8.2/functional:1720
#13 0x0000000000404f90 in std::thread::_Impl<std::_Bind_simple<std::_Mem_fn<void (FetchData::*)()> (std::shared_ptr<FetchData>)> >::_M_run() (this=0xead938)
    at /usr/include/c++/4.8.2/thread:115
#14 0x00007fdc577342b0 in ?? () from /usr/lib64/libstdc++.so.6
#15 0x00007fdc5798ee25 in start_thread () from /usr/lib64/libpthread.so.0
#16 0x00007fdc56e9c34d in clone () from /usr/lib64/libc.so.6

Thread 1 (Thread 0x7fdc57d9e740 (LWP 18734)):
#0  0x00007fdc5798ff57 in pthread_join () from /usr/lib64/libpthread.so.0
#1  0x00007fdc57734077 in std::thread::join() () from /usr/lib64/libstdc++.so.6
#2  0x0000000000401292 in main () at deadlock.cpp:131
(gdb) 
(gdb) 

6. 发现线程号为2和3的线程栈卡在lock_wait或者类似调用上，说明这几个线程极有可能产生死锁

7. info threads可以查看运行的线程，行首的数字表示gdb分配的线程号，切换线程时使用该号码，*表示的 是当前线程
(gdb) info threads
  Id   Target Id         Frame 
  3    Thread 0x7fdc50a40700 (LWP 18735) 0x00007fdc5799542d in __lll_lock_wait () from         /usr/lib64/libpthread.so.0
  2    Thread 0x7fdc5023f700 (LWP 18736) 0x00007fdc5799542d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
* 1    Thread 0x7fdc57d9e740 (LWP 18734) 0x00007fdc5798ff57 in pthread_join () from /usr/lib64/libpthread.so.0
(gdb) 

8. 利用thread ID命令切换到怀疑的线程，打印锁的信息，Owner字段表示哪个线程持有这把锁，它是线程的lwp号，可以通过info threads查看，这里我们查看线程3，并打印堆栈信息
(gdb) thread 3
[Switching to thread 3 (Thread 0x7fdc50a40700 (LWP 18735))]
#0  0x00007fdc5799542d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
(gdb) bt
#0  0x00007fdc5799542d in __lll_lock_wait () from /usr/lib64/libpthread.so.0
#1  0x00007fdc57990dcb in _L_lock_812 () from /usr/lib64/libpthread.so.0
#2  0x00007fdc57990c98 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0
#3  0x00000000004010dc in __gthread_mutex_lock (__mutex=0xeab098) at /usr/include/c++/4.8.2/x86_64-redhat-linux/bits/gthr-default.h:748
#4  0x000000000040141e in std::mutex::lock (this=0xeab098) at /usr/include/c++/4.8.2/mutex:134
#5  0x0000000000402575 in std::unique_lock<std::mutex>::lock (this=0x7fdc50a3fd80) at /usr/include/c++/4.8.2/mutex:511
#6  0x0000000000401f99 in std::unique_lock<std::mutex>::unique_lock (this=0x7fdc50a3fd80, __m=...) at /usr/include/c++/4.8.2/mutex:443
#7  0x000000000040183f in DataPool::pushToPool (this=0xeab058, inputData=std::shared_ptr (count 2, weak 0) 0x7fdc480008c0) at deadlock.cpp:53
#8  0x0000000000401c45 in FetchData::pushData (this=0xeab028) at deadlock.cpp:109
#9  0x0000000000405414 in std::_Mem_fn<void (FetchData::*)()>::_M_call<std::shared_ptr<FetchData>>(std::shared_ptr<FetchData>&&, void const volatile*) const (this=0xead6b0, 
    __ptr=<unknown type in /home/hls/demo/gdb/a.out, CU 0x0, DIE 0xbe6d>) at /usr/include/c++/4.8.2/functional:558
#10 0x00000000004053a8 in std::_Mem_fn<void (FetchData::*)()>::operator()<std::shared_ptr<FetchData>, , void>(std::shared_ptr<FetchData>&&) const (this=0xead6b0, 
    __object=<unknown type in /home/hls/demo/gdb/a.out, CU 0x0, DIE 0xbe6d>) at /usr/include/c++/4.8.2/functional:610
#11 0x0000000000405261 in std::_Bind_simple<std::_Mem_fn<void (FetchData::*)()> (std::shared_ptr<FetchData>)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0xead6a0)
    at /usr/include/c++/4.8.2/functional:1732
#12 0x00000000004050b1 in std::_Bind_simple<std::_Mem_fn<void (FetchData::*)()> (std::shared_ptr<FetchData>)>::operator()() (this=0xead6a0) at /usr/include/c++/4.8.2/functional:1720
#13 0x0000000000404f90 in std::thread::_Impl<std::_Bind_simple<std::_Mem_fn<void (FetchData::*)()> (std::shared_ptr<FetchData>)> >::_M_run() (this=0xead688)
    at /usr/include/c++/4.8.2/thread:115
#14 0x00007fdc577342b0 in ?? () from /usr/lib64/libstdc++.so.6
#15 0x00007fdc5798ee25 in start_thread () from /usr/lib64/libpthread.so.0
#16 0x00007fdc56e9c34d in clone () from /usr/lib64/libc.so.6
(gdb) 

9. 可以看到堆栈最终卡在源码中的第53行，堆栈的第7层，我们使用frame命令查看第7层具体信息
(gdb) frame 7
#7  0x000000000040183f in DataPool::pushToPool (this=0xeab058, inputData=std::shared_ptr (count 2, weak 0) 0x7fdc480008c0) at deadlock.cpp:53
53			std::unique_lock<std::mutex> lckTwo(mutexTwo_);
(gdb) 

10. 查看一下lckTwo这把锁和mutexTwo_的信息
(gdb) p lckTwo 
$1 = {_M_device = 0xeab098, _M_owns = false}
(gdb) p mutexTwo_ 
$2 = {<std::__mutex_base> = {_M_mutex = {__data = {__lock = 2, __count = 0, __owner = 18736, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, 
      __size = "\002\000\000\000\000\000\000\000\060I\000\000\001", '\000' <repeats 26 times>, __align = 2}}, <No data fields>}
(gdb) 
# 这里我们可以看到线程3当前没有拥有lckTwo这把锁，互斥量mutexTwo_当前被lwp号为18736的线程占有，即线程2，那么这个时候我们就找到了死锁的具体点，通过审查线程2执行的代码，死锁很快就能定位出来。我们这段代码是有意地构造死锁条件，进行逆推。不过真实开发中出现的死锁问题，也可以通过gdb调试结合core dump分析来解决。


 

--~Vampire
关注
  • 1
    点赞
  • 踩
  • 11
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
使用gdb帮助定位并发程序中的死锁
runyon的博客
10-10 698
对于复杂的并发程序来说，死锁是个让人头疼的问题。本文提出的是一种亡羊补牢的方法：当程序运行发现异常时，通过gdb查看程序的运行状态，从而发现和定位隐藏错误——比如死锁。     先故意写一段会导致死锁的代码： ===========================代码的分隔线========================================== #include #includ
C++(Qt)软件调试-线程死锁调试（15）
最新发布
10-25
通过熟练运用各种调试工具，结合对线程同步机制的深入理解，开发者可以有效地定位并解决这类问题，保证程序的正常运行。无论是在Linux还是Windows系统下，GDB和Windbg都是强大的武器，能够帮助开发者在遇到死锁时...
gdb定位死锁问题
strut的博客
09-15 1349
本案例借着gdb调试死锁的问题，演示在多线程场景下如何使用gdb调试多线程死锁的 调试过程： 1.为了重现死锁现象，自己写了个死锁demo [root@localhost bin]# ./deadLock thread_routine_two:lock mutex two thread_routine_one:lock mutex one thread_routine_one:lock mutex two thread_routine_two:lock mutex one 2....
gdb定位死锁
yxf1993的博客
04-21 199
【操作系统】GDB 精确定位死锁位置技巧
Michael
04-19 1710
需要注意的是，如果程序中有多个线程同时等待同一个互斥锁，那么通过查看调用栈可能无法确定当前线程正在等待哪个互斥锁。此时，可以通过查看互斥锁的地址，以及在其他线程中调用。命令查看当前进程中所有线程的信息，包括线程 ID、状态、调用栈等信息。通过查看线程的调用栈，可以得知当前线程正在等待哪个互斥锁。找到当前正在运行的线程，并查看其调用栈。如果有，可以查看其参数，即可得知当前线程正在等待哪个互斥锁。函数的调用，可以查看其参数，即可得知当前线程正在等待哪个互斥锁。命令查看当前进程中所有线程的信息。
gdb 定位死锁问题
聆听风雨的博客
12-20 381
gdb 定位死锁问题
gdb多线程调试
07-31
### gdb多线程调试知识点详解 #### 一、gdb简介 gdb（GNU调试器）是GNU项目中的一部分，是一种强大的开源调试工具，...特别是在面对复杂的多线程环境时，合理的使用gdb进行调试将极大地提高问题定位的速度和准确性。
Debugging with GDB 用GDB调试多线程程序
05-29
在Linux环境下，GDB（GNU调试器）是进行程序调试的强大工具，尤其在处理复杂多线程程序时，GDB提供了丰富的功能来帮助开发者定位和解决问题。本文将详细介绍如何利用GDB的特性来有效地调试多线程程序。 #### 基本...
使用GDB调试C++代码专业技术
10-23
- **多线程调试**：当程序包含多个线程时，GDB支持同时跟踪多个线程的执行情况，这对于诊断多线程程序中的死锁等问题非常有帮助。 #### 总结 本文详细介绍了使用GDB调试C++代码的专业技术，包括调试的基本概念、GDB...
GDB手册中文200页
04-23
详细阐述了如何使用GDB来排查程序中的错误，包括内存泄漏、死锁等问题。 ### 六、调试符号表 #### 6.1 符号表介绍 这部分内容介绍了符号表的概念及其在GDB中的作用，符号表对于理解程序结构和调试过程至关重要。 ...
GDB调试精粹及使用实例
01-01
本文档用于的unix下GDB调试，文中包含简单的gdb调试命令使用方法，并提供了用例
使用gdb调试死锁线程
波波诸葛伟
10-24 1000
1.调试文件 lock.c   #include &lt;stdio.h&gt; #include &lt;pthread.h&gt; #include &lt;unistd.h&gt; void *work_thread(void *arg) { pthread_mutex_t mutex; pthread_mutex_init(&amp;mutex, 0); usleep(100...
gdb定位死锁位置
qq_42370809的博客
06-22 817
使用gdb定位死锁的两种方法，差别在程序的调用上。
gdb如何定位死锁的位置
Black.Spider的博客
07-21 1202
实例代码如下： #include <iostream> #include <mutex> #include <thread> using namespace std; //互斥锁 mutex mtx; //线程共享资源 int i = 0; //线程入口函数 void func() { mtx.lock(); cout << "进入线程！" << endl; ++i; } int main() { thread t1(func); t
一个使用gdb定位死锁的方法！！
jimmyleeee的专栏
08-05 2805
今天遇到了死锁问题，整个server都不能工作，下面分享一下解决的步骤，仅供参考：1） 使用gdb attach那个进程2） 使用命令thread apply all bt，把所有的线程的调用栈打出来3） 分析所有线程目前死在哪个锁，然后分析每个线程使用锁的顺序，发现经过层层嵌套，出现了A,B两个线程 A： 先拿锁1，再拿锁2
在linux上使用gdb分析死锁问题
qq_38993096的博客
05-20 193
学习1 学习2 死锁代码解读： #include<bits/stdc++.h> #include "unistd.h" using namespace std; pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_t mutex2 = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_t mutex3 = PTHREAD_MUTEX_INITIALIZER; pthread_mut
gdb调试进程卡死的问题
weixin_44333998的博客
05-15 1537
服务器莫名有时会卡死，且用valgrind drd发现不是加锁问题，可以用gdb attach调试，但attach后显示代码入口为deadbeaf/0: gedit vim /etc/sysctl.d/10-ptrace.conf 最后一行改为kernel.yama.ptrace_scope = 0 注意attach后更换线程需要detach 开始时以为是程序死了gdb都控制不到，但后来想gdb的控制显然是与程序是否卡死无关的 参考 ...
如何使用gdb调试多线程死锁问题，并定位触发死锁的线程
buknow的博客
06-08 1765
gdb调试多线程、多线程死锁问题
GDB调试多线程：命令总结与死锁排查
`gdb`（GNU Debugger）是Linux和Unix环境下的一款强大调试工具，能够帮助开发者深入理解程序运行状态，定位并解决各种问题，包括多线程死锁和性能优化等。以下是对`gdb`调试常用命令的详细说明： 1. **多线程调试**...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值