多线程中快速定位段错误位置

参考链接:https://blog.csdn.net/u011426247/article/details/79736111

在做嵌入式Linux开发的时候,程序很容易出现段错误。段错误一般是内存操作指针出错或是内存溢出等问题,有的时候系统会有一点错误提示,但有的时候就直接提示个Segmentation fault (core dumped) 。如果程序是单线程,那很好处理,编译的时候添加参数-g  ,直接使用gdb 单步调试就可以直接定位到问题点在哪了。但是对于多线程,情况就不一样了。多线程进行单步调试不好处理,并且时候程序需要运行很久才出来段错误。这样直接使用gdb单步调试就不合适了。这里提供一种快速定位段错误的方式。

1.ulimit 命令设置core文件的最大值
1.1执行ulimit -a, 查看core文件的最大值,一般默认值是0

[email protected]:~/test/FWH/9th_DiskTest$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 3712
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 3712
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

1.2执行命令:ulimit -c unlimited
[email protected]:~/test/FWH/9th_DiskTest$ ulimit -c unlimited
[email protected]:~/test/FWH/9th_DiskTest$ ulimit -a 
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 3712
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 3712
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
[email protected]:~/test/FWH/9th_DiskTest$

可以看到core file size  已经被修改为不受限制,运行程序的时候会在当前目录生成一个core文件
[email protected]:~/test/FWH/9th_DiskTest$ ls
core  Diskmanage  EncodeReadWrite  IndexManage  main.cpp  main.o  Makefile  sharestruct.h  test

2.使用gdb调试:
[email protected]:~/test/FWH/9th_DiskTest$ sudo gdb test core 
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are 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 was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test...done.
[New LWP 7445]
[New LWP 7440]
[New LWP 7441]
[New LWP 7443]
[New LWP 7444]
[New LWP 7442]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./test‘.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000004046c0 in StorageService::VideoWriteThread (this=0x71e470, arg=0x7fffac5cbccc)
    at EncodeReadWrite/StorageService.cpp:627
627                             l_s32Ret = l_pAudioQue[i]->ReadQueue(i,(void*)l_pAudioDataOut[i]);
[Current thread is 1 (Thread 0x7f32e0fa5700 (LWP 7445))]
(gdb) printf i
Bad format string, missing ‘"‘.
(gdb) print i 
$1 = 6
(gdb) q
[email protected]:~/test/FWH/9th_DiskTest$

上面的test 为我的可执行程序。
这样可以精确的定位到出现段错误的函数行,并可以查看各参数的值,这样定位起来就很快了。

注意:在一个shell 线程中,core file size 值只能被修改一次,如果取消之后再修改会出现错误:
-bash: ulimit: core file size: cannot modify limit: Operation not permitted
解决这一问题的方法是exit退出该shell,重启一个shell 就可以了。

原文地址:https://www.cnblogs.com/edan/p/10240472.html

时间: 2024-11-08 10:17:39

多线程中快速定位段错误位置的相关文章

通过gdb快速定位“段错误”的位置

有些时候我们在一段 C/C++ 代码的时候,由于对一个非法内存进行了操作,在程序运行的过程中,出现了"Segmentation fault (core dumped)"--段错误. 呵呵,这种问题我想很多人会经常遇到.遇到这种问题是非常无语的,只是提示了"段错误",接着什么都没有,如果我们一味的去看代码找太疼苦了,因为我们都相信自己写的代码没问题,现实就是现实.接着,我们可能通过打印来定位到段错误的位置,这样会有个问题,如果代码量大,我们需要打印很多信息才能找到&q

linux c 用户态调试追踪函数调用堆栈以及定位段错误[转载]

一般察看函数运行时堆栈的方法是使用GDB(bt命令)之类的外部调试器,但是,有些时候为了分析程序的BUG,(主要针对长时间运行程序的分析),在程序出错时打印出函数的调用堆栈是非常有用的. 在glibc头文件"execinfo.h"中声明了三个函数用于获取当前线程的函数调用堆栈. int backtrace(void **buffer,int size) 该函数用于获取当前线程的调用堆栈,获取的信息将会被存放在buffer中,它是一个指针列表.参数 size 用来指定buffer中可以保

linux下利用backtrace追踪函数调用堆栈以及定位段错误

一般察看函数运行时堆栈的方法是使用GDB(bt命令)之类的外部调试器,但是,有些时候为了分析程序的BUG,(主要针对长时间运行程序的分析),在程序出错时打印出函数的调用堆栈是非常有用的. 在glibc头文件"execinfo.h"中声明了三个函数用于获取当前线程的函数调用堆栈. [cpp] view plain copy print? int backtrace(void **buffer,int size) 该函数用于获取当前线程的调用堆栈,获取的信息将会被存放在buffer中,它是

Linux下利用backtrace追踪函数调用堆栈以及定位段错误[转]

来源:Linux社区  作者:astrotycoon 一般察看函数运行时堆栈的方法是使用GDB(bt命令)之类的外部调试器,但是,有些时候为了分析程序的BUG,(主要针对长时间运行程序的分析),在程序出错时打印出函数的调用堆栈是非常有用的. 在glibc头文件"execinfo.h"中声明了三个函数用于获取当前线程的函数调用堆栈. int backtrace(void **buffer,int size) 该函数用于获取当前线程的调用堆栈,获取的信息将会被存放在buffer中,它是一个

Eclipse中快速定位

Eclipse中快速定位 选中项目,ctrl+h 一.目标 查找如下的页面属于哪个activity 二.步骤 1.查找关键字 上述页面中"点我"两个字比较显眼,我们可以去android项目中搜索出现"点我"两个关键字的位置 2.搜索 选中项目.ctrl+h 定位 点进去后出现 用同样的方法在button出现的位置,因为button肯定会被layout引用,layout又会被activity引用 找button之后的结果,再用同样方法找btn_openActivity

c# JD快速搜索工具,2015分析JD搜索报文,模拟请求搜索数据,快速定位宝贝排行位置。

分析JD搜索报文 搜索关键字 女装 第二页,分2次加载. rt=1&stop=1&click=&psort=&page=3http://search.jd.com/Search?keyword=%E5%A5%B3%E8%A3%85&enc=utf-8#keyword=%E5%A5%B3%E8%A3%85&enc=utf-8&qrst=UNEXPAND&as=1&qk=title_key%2C%2C%E5%A5%B3%E8%A3%85&

apache安装php7过程中遇到到段错误

1.假如apache的配置文件httpd.conf同时加载libphp5.so和libphp7.so 2.如图所示,modules下同时存在libphp5.so/libphp7.so 3.启动apache,遇到下列错误 4.解决办法就是卸载php5:yum remove php;因为我是yum方式安装的php5,所有yum remove卸载掉即可 同时在httpd.conf中注释掉php5的模块

段错误Segment Fault定位,即core dump文件与gdb定位

使用C++开发系统有时会出现段错误,即Segment Fault.此类错误程序直接崩溃,通常没有任何有用信息输出,很难定位bug,因而无从解决问题.今天我们介绍core dump文件,并使用gdb进行调试,以此来定位段错误问题.此文同时用以备忘. 一.core dump Core dump也称核心转储, 当程序运行过程中异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 称之为core dump文件. 系统默认不生成core dump文件,可以使用ulimit命令进行查看和设

【Z】段错误Segment Fault定位,即core dump文件与gdb定位

使用C++开发系统有时会出现段错误,即Segment Fault.此类错误程序直接崩溃,通常没有任何有用信息输出,很难定位bug,因而无从解决问题.今天我们介绍core dump文件,并使用gdb进行调试,以此来定位段错误问题.此文同时用以备忘. 一.core dump Core dump也称核心转储, 当程序运行过程中异常退出时, 由操作系统把程序当前的内存状况存储在一个core文件中, 称之为core dump文件. 系统默认不生成core dump文件,可以使用ulimit命令进行查看和设