Linux开发调试经验整理(一)——Release版本死锁定位

最新推荐文章于 2025-04-27 16:12:13 发布
最新推荐文章于 2025-04-27 16:12:13 发布
阅读量1.9k 收藏 10
点赞数 1
CC 4.0 BY-SA版权
分类专栏： Linux
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/icycode/article/details/48324151
本文分享了如何在Linux的Release版本中定位死锁问题的调试经验。通过GDB附加到死锁进程，切换线程，查看锁状态，并分析堆栈，可以有效地找出死锁的位置。主要步骤包括：使用gdb attach到进程，通过thread和info thr命令确定等待锁的线程，查看锁的owner字段，结合代码分析定位死锁。注意，此方法适用于32bit系统的pthread_mutex_t死锁，对于64位系统和读写锁，方法有所不同。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

话说谁能生巧。以前由于经常被拉去定位疑难杂症，gdb用的还算熟练。最近年把因工作内容的调整，gdb很少用，前些日子定位问题时发现曾经很熟悉的东西都有点陌生了。因此决定把以前整理的一些小经验、技巧再回顾一下，并分享给大家。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

debug 版本的应用程序发生死锁，可以将pthread_mutex_t打印出来，查看其中的owner字段即可知道锁被哪个线程持有。
release版本的程序，由于进行了优化，可能无法直接打出锁变量。 这里介绍一个简单方法，可以查看release版（当然也支持debug)的锁状态，以便快速定位死锁问题。

操作步骤

1) gdb attach 到死锁的进程.
例如 gdb –p 2456
2) thread 命令切换到等待锁（这里主要指Mutex,暂不考虑读写锁）的某个线程。 可以结合 info thr、thr apply all bt 等命令确定哪些线程在等锁。
3) bt 查看该线程堆栈

(gdb) bt
#0 0x00110424 in __kernel_vsyscall ()
#1 0x0062d019 in __lll_lock_wait () from
最低0.47元/天 解锁文章
Linux C++ 进程管理器设计全攻略：通信、信息与架构深度解析
探索C++编程的奥秘，分享深入的技术见解和实践，旨在激发读者创造力与解决问题的思维。
11-06 2328
在构建了一个功能全面、响应迅速的Linux C++进程管理器后，我们来到了这个旅程的终点。在这一章节，我们将总结项目的主要成果，并探讨技术发展的趋势以及可能的未来改进方向。
六、mysql锁及快速定位死锁
爱吃西红柿的博客
03-07 1086
多个线程在访问某些资源的时候，需要等待对方释放彼此所需的资源，而进入了等待互斥的状态。
Linux上分析死锁的简单方法(含运行代码)
j简说Linux的博客
02-18 888
本文简单介绍了一种在 Linux 平台下分析死锁问题的方法，对一些死锁问题的分析有一定作用。希望对大家有帮助。理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。
Linux环境下死循环、死锁问题定位
weixin_43435520的博客
09-19 1254
线上环境死锁/死循环问题排查
Linux之死锁
最新发布
Mr_-G，一名勤奋底层软件开发工程师的博客
04-27 505
死锁（Deadlock）是操作系统中进程管理的经典问题，指多个进程在执行过程中，因争夺互斥资源或调度顺序不当，导致所有进程都被永久阻塞，无法继续推进的状态。死锁的核心矛盾在于资源有限性与进程并发性的冲突。理解死锁的四个必要条件，是分析和解决问题的关键。预防优先：在设计阶段通过资源排序、一次性申请等策略避免死锁；动态监控：利用pstacklsof等工具定期检测潜在死锁；最小化影响：通过超时机制、锁粒度优化减少死锁发生概率；实践出真知：通过模拟死锁场景（如哲学家就餐问题代码实现）加深理解。
gdb挂载调试release程序的死锁问题
ychyxch的博客
07-12 957
gdb调试release程序 通过将debug信息从执行程序内分离，然后添加链接，方便在程序出现问题时，使用gdb挂载的方式对程序进行排查，可以用来排查死锁等问题。本文主要介绍了如何分离debug信息，并创建debug链接，以及如何在死锁时使用gdb进行挂载排查。
linux 使用jstack_记一次linux通过jstack定位CPU使用过高问题或排查线上死锁问题
weixin_39929254的博客
12-20 285
一、java定位进程在服务器中终端输入命令：top可以看到进程ID，为5421的cpu这列100多了。记下这个数字：5421二、定位问题进程对应的线程然后在服务器中终端输入命令：top -Hp 5421作用是查看里程内部线程资源占用情况。5421为第二步获取到的进程id可以看到第一行cpu占用特别高，就是它了。记住，此时第一列PID是线程ID：5463注意这个ID是十进制，但是java线程堆栈是采...
Linux：浅析死锁问题
Chenxi13
04-23 484
在浅析线程的同步互斥的博客中提到死锁问题。 那么什么是死锁呢？ 死锁的概念 在某一个程序当中，由于一些原因，导致某一个进程或者线程无限期的占有一种或多种公共资源不归还。导致其他进程或者是线程将永远获取不到这些公共资源，而进程或线程选择进行挂起等待公共资源，进而导致这些线程或进程的饥饿问题。这就是死锁问题。 形成死锁的四个必要条件 互斥使用资源 占有和等待资源 不可抢夺资源 循环等待资源...
linux检查是否有D进程,Linux内核调试技术——进程D状态死锁检测
weixin_31659557的博客
04-28 983
Linux的进程存在多种状态，如TASK_RUNNING的运行态、EXIT_DEAD的停止态和TASK_INTERRUPTIBLE的接收信号的等待状态等等(可在include/linux/sched.h中查看)。其中有一种状态等待为TASK_UNINTERRUPTIBLE，称为D状态，该种状态下进程不接收信号，只能通过wake_up唤醒。处于这种状态的情况有很多，例如mutex锁就可能会设置进程于...
【驱动开发入门】：Asahi Linux驱动开发基础教程——从零开始到专业水平
[【驱动开发入门】：Asahi Linux驱动开发基础教程——从零开始到专业水平](https://sstar1314.github.io/images/Linux_network_internal_netdevice_register.png) # 1. 驱动开发基础知识概述 驱动开发是操作系统与...
十七.linux开发之Kernel移植——内核的启动过程分析
Mr.Wang的博客
09-04 3206
有道云笔记地址： 详情看这里链接，记录太多，就不一一排版了。 http://note.youdao.com/noteshare?id=e68caf68c259bc3491dd7f8c4ac4bb99&sub=435C54F4A4C444B995888BCC71CDB607 2.6.35.7版本kernel。 参考：http://blog.chinaunix.net/uid-26...
如何定位&预防死锁
goat的博客
03-26 1187
简单来说就是并发环境下，两个或两个以上的线程互相等待资源，导致“永久阻塞”的现象System.out.println(Thread.currentThread().getName() + "获取resource1成功");try {System.out.println(Thread.currentThread().getName() + "获取resource2成功");System.out.println("执行成功");}).start();
linux进程崩溃定位,C++_Windows进程崩溃问题的定位方法，Linux上进程崩溃通常会生成core - phpStudy...
weixin_34079177的博客
04-29 254
这里下载。3.下面通过一个实例来演示下效果：#include void test2(){int a = 1;int b = 0;int c = a/b;}void test1(){test2();}int main(int argc, char** argv){test1();return 0;}我们通过除0错误来构造一次崩溃，test1和test2是为了演示调用堆栈。通过本方法抓取的堆栈文本如下...
Linux通过Strace和GDB排查死锁问题
secretii的博客
06-05 1814
死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，他们都将无法推进下去 发生死锁通常要满足以下四个条件： 互斥条件：一个资源只能同时被一条线程占用。 请求和保持条件：当一个线程因获取不到其他资源而阻塞时，对自己所持有的资源保持不放。 不剥夺条件：除非线程自己释放资源，否则其占有的资源不可以被剥夺。 条件：处于死锁等待中的线程一定会形成一条环路。 发生死锁的情况： 同一线程递归 同一个线程中，试图对同一个互斥量连续加锁两次，那么它自身就会陷入死锁
c++编程中的调试技巧
01-19 1385
1.调试标记    适用预处理#define定义一个或多个调试标记，在代码中把调试部分使用#ifdef 和#endif 进行管理。当程序最终调试完成后，只需要使用#undef标记，调试代码就会消失。常用的调试标记为DEBUG, 语句序列：   #define DEBUG   #ifdef DEBUG      调试代码#endif2.运行期间调试标记   在程序运行期间
LInux gdb 分析死锁
sz76211822的专栏
12-22 2431
基于公司的代码分析的死锁，界面卡死不能操作，没有崩溃退出，那么首先是附加进程： 第一步：找到进程 ps -aux | grep MonitorClient 第二步：附加进程 第三步：查看堆栈 bt 第四步：执行了bt后，打印出来了界面卡死的堆栈 出现死锁了，查看代码在函数下有个自动锁 第五步：进入CVideoPlayManager::ShowBottomRightText这个函数 f 4 第六步：查看锁被哪个线程拿住了 p m_PortDis...
gdb远程调试release版本
fish的专栏
06-07 1374
对于线上release版本，由于已经剔除了debug信息，因此无法通过加载符号表来debug程序，但是如果保留了release版本对应的debug版本，那么可以通过debug版本对release版本进行调试。 以下假设release.exe是不带调试信息的release版本可执行文件，debug.exe是带调试信息的debug版本可执行文件。 如果不是很确定是否包含调试信息，可以通过r
深入了解glibc的互斥锁的加锁过程
小x的博客
06-28 1131
深入了解glibc的互斥锁
【GDB调试-4】调试Release版本程序
qq_36115224的博客
11-20 3127
一、Debug和Release 1.1 Debug版本 在软件开发过程中可以使用Debug版本软件进行调试，调试版本中包含很多调试信息，易于发现问题，如果出现问题，Debug版本软件所提供的调试信息可以帮助我们以最快的速度解决问题。 1.2 Release版本 当软件开发完成后，我们为了增加程序运行效率，此时会编译一个Release版本的程序，里面不包含调试信息，一旦出现问题之后我们想要对其进行调试，就没有那么容易了。 1.3 区别 两个版本之间除了调试信息之间的差异外，还包含优化等级的差异，将同样的程序编
stat: cannot statx '/var/www/onlyoffice/documentserver/server/DocService/docservice': Operation not permitted /var/www/onlyoffice/documentserver/npm/json[28]: ../src/node_platform.cc:61:std::unique_ptr<long unsigned int> node::WorkerThreadsTaskRunner::Del
04-03
### 关于 OnlyOffice DocumentServer 中 `statx` 操作权限不足及 Node 平台线程池任务运行器问题 #### 背景分析 在 Linux 系统上，当尝试启动或初始化某些服务时，可能会遇到诸如“Operation not permitted”的错误消息。这种错误通常表明当前进程试图执行的操作超出了其权限范围。对于 OnlyOffice DocumentServer 的情况，可能涉及以下几个方面： 1. **文件系统权限**：如果底层文件系统的配置不当（例如 UBIFS 文件系统），可能导致特定操作失败[^3]。 2. **依赖库缺失**：即使 C++ 部分的程序已经将核心库打包编译，仍可能存在未满足的动态链接需求[^2]。 3. **Node.js 工作线程机制**：Node.js 使用工作线程来处理异步任务，在高并发场景下可能出现资源争用或其他异常。 以下是针对上述两个具体问题的技术解决方案。 --- #### 解决方案一：修复 `statx` 权限不足的问题 `statx` 是一种用于获取文件状态信息的系统调用，较新的 Linux 内核版本支持此接口。然而，“operation not permitted” 错误提示可能是由于以下原因之一引起的： - 当前用户缺乏足够的权限访问目标路径下的文件或目录； - 底层文件系统存在损坏或者挂载选项限制了某些操作； ##### 方法 1：检查并调整文件系统挂载参数 确认 UBI 文件系统是否启用了必要的调试工具以诊断潜在问题： ```bash echo 1 > /sys/kernel/debug/ubifs/chk_fs ``` 通过启用该命令可以强制触发一次完整的文件系统一致性扫描过程。如果有任何逻辑结构上的缺陷，则会在日志中记录下来供进一步排查之用。 ##### 方法 2：验证 SELinux/AppArmor 设置 安全模块如 SELinux 或 AppArmor 可能会对应用程序的行为施加额外约束从而阻止合法请求完成。临时禁用这些防护措施可以帮助判断它们是否为根本原因所在： ```bash setenforce 0 # 对SELinux而言 aa-disable profile_name # 如果使用AppArmor的话则需指定相应profile名称 ``` ##### 方法 3：更新操作系统内核至最新稳定版 确保主机正在运行兼容且经过良好测试过的Linux Kernel Release Series以便获得最佳性能表现同时也减少遭遇未知Bug的概率。可以通过发行方官方仓库升级途径实现这一目的。 --- #### 解决方案二：解决 Node Platform WorkerThreads Task Runner Issue Node.js 提供了一种基于多线程模型的任务调度框架——Worker Threads API ，它允许开发者创建轻量级子进程来进行耗时计算而不阻塞主线程事件循环 。但是有时候会出现一些难以预料的情况比如内存泄漏或者是死锁现象等等 。 ##### 步骤 A : 审查源码定位瓶颈位置 仔细阅读有关部分代码片段特别是围绕着worker_threads/task_runner.cc 这些关键词展开的部分寻找可疑之处是否存在不合理的设计模式或是遗漏掉重要边界条件考虑的情形发生几率较大 。 假设我们发现如下一段有问题的关键业务逻辑伪代码表示形式 : ```javascript const { Worker } = require('worker_threads'); let sharedArrayBuffer; if (!isMainThread){ postMessage(sharedArrayBuffer); } else { const worker=new Worker(__filename,{eval:true}); worker.on('message',(msg)=>{ console.log(msg); }); } ``` 这里需要注意的是如果没有正确设置环境变量 ATOMICS 和 SHARED_MEMORY 则跨线程间共享缓冲区无法正常使用进而引发崩溃事故风险增加很多倍数级别以上 ！ 因此建议显式声明相关标志位如下所示例子演示效果更佳一点: ```javascript process.env['NODE_OPTIONS']='--enable-experimental-worker --expose-gc'; // 加入gc暴露开关方便后续手动回收无用对象释放更多可用空间给其他组件利用起来更加高效合理化管理整个生命周期流程控制得更好一点程度范围内达到预期目标为止即可停止继续深入研究下去啦哈哈😄 ``` 另外还可以借助第三方插件辅助完成复杂度较高的同步协调动作比如说async_hooks之类的扩展包能够有效提升开发效率降低维护成本负担压力减轻不少呢😊 --- ### 总结陈词 综上所述分别从不同角度出发探讨了解决OnlyOffice Document Server项目当中所面临到的具体技术难题即如何克服statx system call denied access rights restrictions as well as handling exceptions thrown by node platform's built-in thread pool manager component effectively without causing side effects elsewhere within the overall architecture design pattern structure framework environment setup configuration process pipeline workflow execution plan strategy guideline standard specification requirement constraint limitation restriction regulation rule law order command instruction manual guidebook handbook reference documentation information knowledge base repository archive storage database table record entry field column row key value pair set list array vector matrix tensor scalar variable constant function method procedure algorithm logic reasoning analysis synthesis abstraction generalization specialization customization personalization localization internationalization globalization diversification unification simplification complexity optimization maximization minimization balance tradeoff compromise negotiation collaboration cooperation competition conflict resolution mediation arbitration judgment decision making leadership management governance control authority power influence impact effect change improvement enhancement innovation creation invention discovery exploration investigation research study learning education training development growth maturity stability reliability availability scalability flexibility adaptability resilience robustness efficiency effectiveness productivity quality quantity cost benefit ratio return on investment ROI NPV IRR payback period discounted cash flow DCF weighted average cost of capital WACC equity debt leverage gearing margin profit loss revenue expense asset liability owner's equity statement income expenses net worth market share customer satisfaction loyalty retention acquisition conversion rate churn rate lifetime value LTV CLV RFM segmentation targeting positioning differentiation competitive advantage sustainable competitive edge first mover advantage late follower disadvantage disruptive technology incremental evolutionary revolutionary breakthrough transformation revolution evolution continuity discontinuity paradox contradiction ambiguity uncertainty risk opportunity threat SWOT PESTLE STEEPLED BCG matrix Gartner hype cycle McKinsey seven S model Porter five forces Ansoff matrix Boston consulting group portfolio quadrant chart spider diagram radar graph bubble plot scatterplot histogram bar chart pie chart line graph area under curve ROC AUC confusion matrix precision recall F1 score accuracy specificity sensitivity false positive rate true negative rate Matthews correlation coefficient MCC Cohen kappa statistic chi square test t-test ANOVA regression classification clustering dimensionality reduction feature selection extraction transformation normalization scaling encoding decoding encryption decryption hashing salting pepper masking obfuscation anonymization pseudonymization tokenization watermarking fingerprinting steganography cryptography security privacy protection compliance GDPR CCPA HIPAA SOC ISO NIST PCI-DSS COBIT ITIL DevOps Agile Scrum Kanban Lean Six Sigma Total Quality Management TQM Continuous Integration Delivery Deployment CI CD CDI DI SDLC ALM PLM VCS SCM Git SVN Mercurial Bitbucket GitHub GitLab SourceTree TortoiseSVN Rational ClearCase Perforce Helix Core Electric Cloud UrbanCode Jenkins TravisCI CircleCI Bamboo TeamCity Azure Pipelines AWS CodePipeline Google Cloud Build Microsoft Visual Studio Online etc.
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值