Linux 多线程调试(内存占用、死循环、CPU占用率高……)

文章出处:http://www.cnblogs.com/cy568searchx/archive/2013/10/28/3391790.html

 

 

你的软件在某个时刻停止服务,CPU占用达到100%+,这种问题一个可能的原因是产生了死循环,假设程序某处存在潜在的死循环,并在某种条件下会引发,本文以一个示例来定位出现死循环的位置。
当程序某处存在死循环,通常定位问题及缩小范围的方法是,在可疑的代码处加log,或者注释掉可疑代码,这对于容易重现问题的程序来说还好,但对于“偶尔”才会产生问题程序却很难调试,因为我们很难重现程序故障。本文所述的调试过程正是在这种情况下,假设问题已经出现,我们要求环境保护现场,即出问题的程序还在运行中。

1.我们首先要知道是哪个线程出了问题:
首先查一下出问题进程的pid,例如

ovtsvn@ovtsvn:~/MASS4/src/icdn/src$ ps -ef | grep icdn 

ovtsvn   11065     1 50 11:57 ?        00:00:07 ./icdn 

ovtsvn   11076 10971  0 11:57 pts/2    00:00:00 grep

ovtsvn@ovtsvn:~/MASS4/src/icdn/src$

ovtsvn@ovtsvn:~/MASS4/src/icdn/src$ 

然后top命令查看线程信息:
top -H -p 11065

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                 

11073 ovtsvn    25   0  325m 3980 2236 R  100  0.4   1:40.84 icdn                                                                    

11065 ovtsvn    18   0  325m 3980 2236 S    0  0.4   0:00.01 icdn                                                                    

11066 ovtsvn    18   0  325m 3980 2236 S    0  0.4   0:00.00 icdn                                                                    

11067 ovtsvn    15   0  325m 3980 2236 S    0  0.4   0:00.00 icdn                                                                    

11068 ovtsvn    15   0  325m 3980 2236 S    0  0.4   0:00.00 icdn                                                                    
11069 ovtsvn 180 325m 39802236 S 00.40:00.00 icdn 

11070 ovtsvn 180 325m 39802236 S 00.40:00.00 icdn 

11071 ovtsvn 220 325m 39802236 S 00.40:00.00 icdn 

11072 ovtsvn 150 325m 39802236 R 00.40:00.00 icdn

 

从上面可以看出,出问题线程PID为11073

2.接下来,我们用gdb来attach目标进程
执行: gdb icdn 11065
在gdb中,列出线程状态:

(gdb) info threads   

9 Thread 47056948181264 (LWP 11066)  0x00002acc4a3dec91 in nanosleep () from /lib/libc.so.6   

8 Thread 47056956573968 (LWP 11067)  0x00002acc4a406fc2 in select () from /lib/libc.so.6   

7 Thread 47056964966672 (LWP 11068)  0x00002acc4a3dec91 in nanosleep () from /lib/libc.so.6  

 6 Thread 47056973359376 (LWP 11069)  0x00002acc4a3dec91 in nanosleep () from /lib/libc.so.6   

5 Thread 47056981752080 (LWP 11070)  0x00002acc4a3dec91 in nanosleep () from /lib/libc.so.6   

4 Thread 47056990144784 (LWP 11071)  0x00002acc4a40e63c in recvfrom () from /lib/libc.so.6   

3 Thread 47057194060048 (LWP 11072)  0x00002acc4a406fc2 in select () from /lib/libc.so.6   

2 Thread 47057226893584 (LWP 11073)  CSendFile::SendFile (this=0x2acc5d4aff40, pathname=@0x2acc5d4afee0)     at ../src/csendfile.cpp:101   

1 Thread 47056939784832 (LWP 11065)  0x00002acc4a3dec91 in nanosleep () from /lib/libc.so.6 (gdb) 

gdb已经列出了各线程正在执行的函数,我们需要更多信息,记住11073对应的行首标号,这是gdb为线程分配的id,这里为2,然后执行切换:

(gdb) thread 2 

[Switching to thread 2 (Thread 47057226893584 (LWP 11073))]#0  CSendFile::SendFile (this=0x2acc5d4aff40, pathname=@0x2acc5d4afee0)     at ../src/csendfile.cpp:101 101             while(1) 

(gdb) 

bt一下:

(gdb) bt 

#0  CSendFile::SendFile (this=0x2acc5d4aff40, pathname=@0x2acc5d4afee0) at ../src/csendfile.cpp:101 

#1  0x000000000040592e in CIcdn::TaskThread (pParam=0x7fff617eafe0) at ../src/cicdn.cpp:128 

#2  0x00002acc4a90b73a in start_thread () from /lib/libpthread.so.0 

#3  0x00002acc4a40d6dd in clone () from /lib/libc.so.6 

#4  0x0000000000000000 in ?? ()

来看一下101行的代码:

(gdb) l 

96      } 

97 

98      int CSendFile::SendFile(const string& pathname) 

99      {

100             int n;

101             while(1)

102             {

103                     n++;

104             }

105             //read file and send 

现在我们定位到了出问题的代码位置,这里的循环只用来演示的。 
最后别忘了detach()

调试完指定进程后,可以运行detach命令来让GDB释放该进程,该进程得以继续运行。当回车时,detach不会重复。当执行完detach后,进程和GDB不再相关,GDB可以attach其他进程。

时间: 2024-09-23 20:05:47

Linux 多线程调试(内存占用、死循环、CPU占用率高……)的相关文章

CPU占用率高的疑因总结和解决方法

  一般情况下CPU占用率高我们的电脑就会慢下来,而很多时候我们总是纳闷不知道原因何在,本文略总结它的疑因以及解决方法,再遇到这情况时我们可以通过做一点点的改动就可以解决. 首先是考虑病毒! 其次: 1.防杀毒软件造成故障 由于新版的KV.瑞星等杀毒软件加入了对网页.插件.邮件的随机监控,无疑增大了系统负担.处理方式:基本上没有合理的处理方式,尽量使用最少的监控服务吧,或者,升级你的硬件配备. 2.驱动没有经过认证,造成CPU资源占用100% 大量的测试版的驱动在网上泛滥,造成了难以发现的故障原

CPU占用率高的九种可能

经常出现CPU占用100%的情况,主要问题可能发生在下面的某些方面: CPU占用率高的九种可能 1.防杀毒软件造成故障 由于新版的KV.金山.瑞星都加入了对网页.插件.邮件的随机监控,无疑增大了系统负担.处理方式:基本上没有合理的处理方式,尽量使用最少的监控服务吧,者,升级你的硬件配备. 2.驱动没有经过认证,造成CPU资源占用100% 大量的测试版的驱动在网上泛滥,造成了难以发现的故障原因. 处理方式:尤其是显卡驱动特别要注意,建议使用微软认证的或由官方发布的驱动,并且严格核对型号.版本. 3

CPU占用率高的N种原因_服务器

1.防杀毒软件造成故障  由于新版的KV.金山.瑞星都加入了对网页.插件.邮件的随机监控,无疑增大了系统负担.处理方式:基本上没有合理的处理方式,尽量使用最少的监控服务吧,或者,升级你的硬件配备.  2.驱动没有经过认证,造成CPU资源占用100%  大量的测试版的驱动在网上泛滥,造成了难以发现的故障原因. 处理方式:尤其是显卡驱动特别要注意,建议使用微软认证的或由官方发布的驱动,并且严格核对型号.版本.  3.病毒.木马造成  大量的蠕虫病毒在系统内部迅速复制,造成CPU占用资源率据高不下.解

system Idle Process CPU占用率高是什么原因?如何解决

在操作系统服务里面,都没有禁止它的选项::默认它是占用除了当前应用程序所分配的处理器(CPU)百分比之外的所有占用率,下面我们来了解一下system Idle Process CPU占用率高的问题 system Idle Process是Windows页面内存管理进程项.不能禁止,不能结束. 此项CPU使用率越大,说明可供分配的CPU使用率越多,数字越小则表示CPU使用率越少. 简单的多,此项进程越大越好. 一旦应用程序发出请求,处理器会立刻响应的.在这个进程里出现的CPU占用数值并不是真正的占

select-top语句和 order by 语句在数据多时,造成CPU占用率高

问题描述 top语句和 order by 语句在数据多时,造成CPU占用率高 Access 2010,Win7 64位,硬件:G2020+8Gb. 首先问题:如下的SQL语句(ID_No是递增的,现在需要查询最近3项数据,每个字段的和) SELECT Sum(AAA), Count(BBB), Sum(CCC) FROM tb_test where ID_No in (select top 3 ID_No from tb_test order by ID_No desc) 数据在几百条时,可以运

SYSTEM进程的CPU占用率高怎么办

用户有时可能会遇到SYSTEM 进程的CPU 长时间接近100%的情况. 要分析这个植障问题, 传统的方法是要在性能监视器里添加SYSTEM 的所有线程的CPU计数器,然后找出占用cpu最高的线程,再用Process Viewer 和Pstat 工具分析该线程的内存地址,以便找出最可疑的问题模块.这个方法非常复杂,不太适合普通用户. 借助Process Explorer ,就可以很方便地解决一些和驱动程序有关的SYSTEM 进程问题.例如当在Wndows7 系统中插入USB闪存,并启用ReadB

重写控件CPU占用率高

问题描述 我用的线程Timer,CPU占用率很不稳定,一会10%几,一会80%多...如果不用线程Timer的话CPU占用率一直是100%.内存使用为30M左右.这些重写的控件是不是对系统性能影响较大呢?还是因为Timer的原因?我去掉Timer后CPU占用率还是挺高的. 解决方案 解决方案二:机器配置为2G内存,Interl双核CPU.Timer设置为100毫秒.主要为演示ProgressBar设置的.解决方案三:不一定需要重写这些控件,效率低,浪费资源.有些可以做自定义控件.解决方案四:也就

.net的MVC程序调试后iisexpress.exe Cpu占用率很高

问题描述 .net的MVC程序调试后iisexpress.exeCpu占用率很高一调试就占用25%了I5的处理器页面刷新去还能到50%这个是什么原因啊 解决方案 解决方案二:自己找到原因了送分了解决方案三: 解决方案四: 解决方案五:接分来了

Win7系统CPU占用率高如何解决?

  1.打开任务管理器,关闭一些占用CPU较高的进程,但是不要关闭System Idle Process这个进程,这个进程是系统管理的进程,另外有很多个svchost.exe,这些进程也不要随便关闭,不然会引起关机或者系统重启. 2.在"开始"----"运行"中输入:msconfig,然后在打开的"系统配置"对话框的"服务"和"启动"选项中关闭一些不需要开机就启动的程序软件或者后台服务项目. 3.现在的很多