澳门新浦京娱乐场网站-www.146.net-新浦京娱乐场官网
做最好的网站

澳门新浦京娱乐场网站:linux包之gdb之gdb命令与

在linux下开辟难免会际遇bug,可是出于尚未图形IDE,导致debug也变得劳碌,其实只要通晓一些常用的debug工具,一些错误就能够高效消除,本文就介绍一些常用的工具用以调治将养:

linux下debug工具,linuxdebug工具

在linux下支付难免会遭受bug,但是出于尚未图形IDE,导致debug也变得辛苦,其实假如理解一些常用的debug工具,一些谬误就能够非常快消除,本文就介绍部分常用的工具用以调解:

gdb-7.2-64.el6_5.2.x86_64
/usr/bin/gcore
/usr/bin/gdb
/usr/bin/gdb-add-index
/usr/bin/gdbtui
/usr/bin/gstack
/usr/bin/pstack

咱俩能够通过  1)  gdb prog_name -> r               用在稳步调试本身的主次时

log

出口log永世是最轻巧易行火速的调解格局,能够急迅稳固bug,通过设置日志等级决定日志的输出详略程度,结合一些文件解析工具awk/sed/grep能够便捷在大方日志中找到错误音讯。

log

输出log永恒是最简易便捷的调治格局,能够急迅牢固bug,通过安装日志品级决定日志的出口详略程度,结合一些文件分析工具awk/sed/grep能够一点也不慢在大方日志中找到错误音讯。

[root@coreserv tmp]# rpm -qa|grep abr
abrt-libs-2.0.8-6.el6.centos.x86_64
abrt-addon-ccpp-2.0.8-6.el6.centos.x86_64
abrt-2.0.8-6.el6.centos.x86_64
abrt-addon-kerneloops-2.0.8-6.el6.centos.x86_64
abrt-tui-2.0.8-6.el6.centos.x86_64
abrt-cli-2.0.8-6.el6.centos.x86_64
abrt-addon-python-2.0.8-6.el6.centos.x86_64

                    2)  gdb -> attach process_id       正在运营中的后台程序忽然卡在了有个别地方,先ps再gdb/attach

strace

是一个用来追踪系统调用的简练工具。它最简易的用处正是追踪三个顺序整个生命周期里有着的连串调用,并把调用参数和再次来到值以文件的点子出口。Strace还足以追踪发给进度的连续信号。帮助attach正在运维的长河  strace -p <pid>, 当多线程景况下,须要追踪某些线程的系统调用,能够先ps -efL|grep <Process Name> 查寻找该进度下的线程,然后调用starace –p <pid>进行解析。

strace

是三个用来追踪系统调用的简要工具。它最简易的用途正是追踪一个顺序整个生命周期里装有的系统调用,并把调用参数和重返值以文件的不二秘诀出口。Strace还是可以追踪发给进度的时限信号。帮助attach正在运转的进程 strace -p <pid>, 当多线程境况下,必要跟踪某些线程的种类调用,能够先ps -efL|grep <Process Name> 查搜索该进度下的线程,然后调用starace –p <pid>实行分析。

ABRT (Automated Bug Reporting Tool) Daemon:
ABRT is an application, included in Fedora Linux Distribution, that is used to report bugs in the software packages whenever crash occurs. Due to this, ABRT also helps in creation of core dump files. Multiple packages may be needed to run various features of ABRT daemon, and their listing is as follows.

                    3)  gdb prog_name core              程序core掉了

pstack

用来追踪进度栈,举个例子大家发掘一个劳动一向处于work状态(如假死状态,好似死循环),使用那几个命令就能够轻轻便松定位难题所在;能够在一段时间内,多试行几回pstack,若觉察代码栈总是停在同三个职位,那一个地方就供给注重关注,一点都不小概正是出题指标地点;

pstack

用来追踪进程栈,比如大家发掘二个服务向来处在work状态(如假死状态,好似死循环),使用那一个命令就会轻巧定位难题所在;能够在一段时间内,多施行两遍pstack,若发掘代码栈总是停在同四个地方,那些地方就供给入眼关注,相当的大概正是出难点的地点;

$service abrtd status

三种艺术对二个主次开展调节和测验;

gdb

经文的调节和测验工具,功能很庞大,注意此时编写翻译的时候应该使用-g选项,并用-Og实行优化。多线程下能够attach到进度来调整。

gdb

经文的调解工具,功用很有力,注意此时编写翻译的时候应该使用-g选项,并用-Og进行优化。三十二线程下能够attach到进程来调解。

$sysctl -a|grep core_pattern
kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp /var/cache/abrt %p %s %u %c

 

core dump文件

在进度收到有个别连续信号而止住运转时,将那儿进度地址空间的内容以及关于进度情形的其余音讯写到core文件中,举个例子我们平素的越轨访谈内部存款和储蓄器发生segment fault错误,利用gdb能够查看见到底是哪里产生了老大。不经常候能够人工的向进度发送时限信号kill -11 <pid>,查看此时系统运营的地方,比如四线程下程序猛然停住了,此时就恐怕发生了死锁,能够人工的发出非确定性信号,再来解析core dump。

core dump文件

在进度收到有些非数字信号而告一段落运营时,将那儿历程地址空间的内容以及关于进程景况的别的信息写到core文件中,举例大家一贯的野鸡访谈内部存款和储蓄器发生segment fault错误,利用gdb能够查见到到底是哪儿爆发了要命。不常候能够人工的向进程发送复信号kill -11 <pid>,查看此时系统运营的图景,比如多线程下程序忽地停住了,此时就恐怕爆发了死锁,能够人工的发出实信号,再来分析core dump。

By default, “abrtd” created core dump files only for those executable (or packages) that are managed by “rpm” (red hat package manager) utility. To enable “abrtd” for non-rpm application (something you compiled locally and are not managed through rpm), you need to edit the file cat “/etc/abrt/abrt.conf” , and change the value of the field “ProcessUnpackaged” to “yes” as follows:
千古设置  abrt :
ProcessUnpackaged = no   #(before editing the file)
ProcessUnpackaged = yes  #(after editing the file)

  1. thread——gdb 三十二线程调节和测量试验命令:

valgrind

含蓄众多工具:

Memcheck。这是valgrind应用最遍布的工具,一个重量级的内部存款和储蓄器检查器,能够开掘开辟中山大学部内部存款和储蓄器不当使用状态,举例:使用未起头化的内部存款和储蓄器,使用已经刑释了的内部存储器,内部存储器访问越界等。那也是本文将根本介绍的一部分。

Callgrind。它根本用来检查程序中等学园函授数调用进度中现身的标题。

Cachegrind。它根本用来检查程序中缓存使用出现的题目。

Helgrind。它主要用来检查多线程程序中冒出的竞争难点。

Massif。它首要用来检查程序中客栈使用中出现的主题材料。

Extension。可以采用core提供的效劳,自身编辑特定的内部存款和储蓄器调节和测量试验工具。

私下认可使用的正是memcheck工具,在c 中指针的运用,一不稳重就能产生极其,就能够动用memcheck进行自己斟酌。个人日常用--track-origins=yes来牢固未起头化变量的职位。

valgrind

含蓄众多工具:

Memcheck。这是valgrind应用最常见的工具,多个重量级的内部存款和储蓄器检查器,能够察觉开荒中山大学部内部存款和储蓄器不当采用状态,比如:使用未伊始化的内部存款和储蓄器,使用已经刑释了的内部存款和储蓄器,内部存款和储蓄器访问越界等。那也是本文将第一介绍的片段。

Callgrind。它首要用来检查程序中等学校函授数调用进程中冒出的标题。

Cachegrind。它至关心重视要用来检查程序中缓存使用出现的标题。

Helgrind。它至关主要用来检查二十八线程程序中出现的竞争难点。

Massif。它至关心珍视要用来检查程序中仓库使用中出现的主题素材。

Extension。能够选拔core提供的机能,自身编辑特定的内部存款和储蓄器调节和测试工具。

暗中同意使用的正是memcheck工具,在c 中指针的施用,一不留意就能够爆发特别,就足以行使memcheck举办反省。个人日常用--track-origins=yes来稳固未起初化变量的职责。

gcore命令

 

tcpdump

抓包用的,在支付网络使用的时候很给力,结合awk/sed/grep可以连忙寻找互连网数据包。

stackoverflow

本条网址是个程序设计领域的问答网址,基本境遇的主题材料都能在那当中找到答案! 本领氛围很强,从当中能学到相当多东西。

tcpdump

抓包用的,在开拓互联网使用的时候很给力,结合awk/sed/grep可以长足找出互联网数据包。

stackoverflow

本条网址是个程序设计领域的问答网址,基本碰着的主题素材都能在这里面找到答案! 技能氛围很强,从中能学到比相当多东西。

在linux下支付难免会遭遇bug,不过出于未有图形IDE,导致debug也变得辛勤,其实假若理解一些常用的debug工具,...

问题:
当调节和测验一个程序的时候,理想图景是不重启应用程序就获得core文件。
解决:
gcore命令能够运用上边步骤来赢得core文件:

     info threads:           展现当前历程中的线程;

  1. 承认gdb软件包已经被精确安装。
  2. 行使调节和测量检验参数编写翻译程序(举个例子: gcc中动用"-g"选项),编写翻译后不要去除文件的调理符号音信。
  3. 实行应用程序。
  4. 实践gcore命令生成钦命应用程序的core文件同期保留在当前目录下。
    $ gcore pid   (进程号)

     thread thread_no:  步向线程xx,经常紧接而来的是 bt/f 命令;

core简介

 

Core文件其实正是内部存储器的影象,当程序崩溃时,存款和储蓄内部存款和储蓄器的照管消息,主用用于对前后相继开展调理。当程序崩溃时便会发出core文件,其实精确的应该算得core dump 文件,暗中认可生成职责与可实行程序位于同一目录下,文件名称叫core.***,其中***是某一数字。 导致程序coredump的由来非常多,这里依照以后的经验总结一下:
1 内部存款和储蓄器访谈越界
2 二十多线程程序选拔了线程不安全的函数。
3 八线程读写的数据未加锁爱慕。
对于会被三个线程同期做客的大局数据,应该小心加锁珍爱,不然很轻便导致core dump
4 违法指针
  a) 使用空指针
  b) 随便使用指针转变。
5 旅舍溢出
永不采取大的有个别变量(因为有的变量都分配在栈上),那样轻巧形成饭店溢出,破坏系统的栈和堆结构,导致出现莫明其妙的谬误。

  1. strace/ltrace:

在程序不日常退出时,内核会在当前专门的学问目录下生成二个core文件(是三个内部存款和储蓄器影象,同期加上调节和测量检验音信)。使用gdb来查看core文件,能够提示出导致程序出错的代码所在文件和行数。

     后边八个关切系统调用和程序所吸收接纳的复信号;前面一个关怀库函数调用;

当系统中的一些程序在遭受有的不当以及crash时,系统会活动发出core文件记录crash时刻系统消息,包蕴内存和寄存器音信,用以程序员日 后debug时得以运用。那个错误满含段错误、违法命令、总线错误或客户本身生成的脱离新闻等等,日常地,core文件在现阶段文件夹中寄放。core dump又叫宗旨转储, 当程序运营进程中爆发极其, 程序相当退出时, 由操作系统把程序当前的内部存款和储蓄器情形存款和储蓄在贰个core文件中, 叫core dump. (linux中只要内部存储器越界会摄取SIGSEGV能量信号,然后就能够core dump)

     strace的利用在 大家没有前后相继的源码,或然不便于从头开端运转程序时;能够一本万利查看八个应用程序实行了何等系统调用。

不时某个主题材料只可以在特定的条件下才具再现,再现的火候和标准都不便把握,或许很频仍的测量试验技巧有的时候的重现三遍难题,那给大家的调治和修改都拉动很多不便之处,还会有一种难以追踪调节和测量检验的事态,在巨型的软件项目中,要从数万行依旧越来越多的代码中标准的找到难题所在,靠设断点和单步追踪的措施是很费力很须求时刻的,那些标题能够经过Core Dump的不二秘籍,也许说事后调节和测量试验(postmortem debug)本领,来扶助剖析.重要方法是在前后相继崩溃的时候,将顺序的内部存款和储蓄器映象加上调节和测量试验消息保存到三个文本中,那后透过剖判那几个所谓的Core文件来找到程序崩溃的原因.Core Dump的称呼来源于从前工产业界的叫法---当内部存款和储蓄器依然圆形的时候,它被称之为Core,大家可以使用GDB来深入分析core文件来搜寻出错的因由

     而在期望知晓程序都调用了动态库中的哪些函数时,我们选拔ltrace。ltrace有个-S选项,类似于strace作用。

安装查看当前core文件的系统级配置

 

core文件的变动开关和大小限制

3.检查内存泄漏的工具:

闭馆或堵住core文件生成:
$ulimit -c 0
开辟core文件生成:
$ulimit -c unlimited
检查core文件的选项是还是不是张开:
$ulimit -a

   valgrind (in linux, free) 
   visual leak detector (windows , free)
   boundschecker(windows, free)

只要想经过limits.conf里面包车型地铁装置来决定客商是或不是能够发生core文件,必要把/etc/profile里面包车型大巴ulimits设置注释掉
以上配置只对这几天会话起效果,后一次再一次登入后,依旧得重新配置。要想布置恒久生效,
二种方法
得在/etc/profile恐怕/etc/security/limits.conf文件中开展示公布局。
率先以root权限登入,然后展开/etc/security/limits.conf文件,实行陈设:
#vim /etc/security/limits.conf
<domain>    <type>    <item>        <value>
       *              soft          core         unlimited
抑或在/etc/profile中作如下配置:
#vim /etc/profile
ulimit -S -c unlimited >/dev/null 2>&1
要么想布署只针对某一客户有效,则修改此顾客的~/.bashrc或者~/.bash_profile文件:
ulimit -c unlimited
ulimit -c 0 是明确命令制止发生core文件,而ulimit -c 1024则限制发生的core文件的尺寸不可能超过1024kb
1)使用ulimit -c命令可查看core文件的转移按键。若结果为0,则代表关闭了此意义,不会生成core文件。
2)使用ulimit -c filesize命令,能够界定core文件的轻重(filesize的单位为kbyte)。若ulimit -c unlimited,则意味着core文件的大小不受限制。

   profile工具:
   oprofile
   vtune

proc/sys/kernel/core_pattern 能够安装格式化的 core 文件保留地方或文件名 ,暗中认可的是|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e。供给修改的话,可以选用如下命令:
echo "/media/test/core-%e-%p-%t">/proc/sys/kernel/core_pattern

在奥德赛HEL/CentOS 60人(三13位没用过)6.0之上版本中,有core文件被截断的难点,尽管你曾经设置了ulimit -S -c unlimited。
缘由好疑似因为core pattern设置是abrt,abrt的难题导致core文件非常小可能不产生core文件。消除的主意是不行使abrt作为core pattern。
要是core pattern设置成了abrt,改成core形式:
先查看当前系统装置
[root@localhost log]# sysctl -a | grep core_pattern
kernel.core_pattern = core
linux-y94w:/ # sysctl -w kernel.core_pattern=core.%p.%e
kernel.core_pattern = core.%p.%e
或者:
linux-y94w:/ # sysctl -w kernel.core_pattern=core.%p
kernel.core_pattern = core.%p

core文件名与变化路线
/proc/sys/kernel/core_pattern能够操纵core文件保留地点和文书名格式。
澳门新浦京娱乐场网站:linux包之gdb之gdb命令与core文件产生。可经过以下命令修改此文件:
echo "/corefile/core-%e-%p-%t" > core_pattern,能够将core文件统平生成到/corefile目录下,爆发的文书名称叫core-命令名-pid-时间戳
以下是参数列表:
    %p - insert pid into filename 添加pid
    %u - insert current uid into filename 增加当前uid
    %g - insert current gid into filename 增加当前gid
    %s - insert signal that caused the coredump into the filename 增多导致发生core的时域信号
    %t - insert UNIX time that the coredump occurred into filename 增多core文件生成时的unix时间
    %h - insert hostname where the coredump happened into filename 增多主机名
    %e - insert coredumping executable name into filename 加多命令名
[root@localhost log]# cat /proc/sys/kernel/core_pattern
core
[root@localhost log]# cat /proc/sys/kernel/core_pipe_limit
0
/proc/sys/kernel/core_uses_pid能够调控core文件的文书名中是或不是加多pid作为扩充。文件内容为1,表示加多pid作为扩展名,生成的core文件格式为core.xxxx;为0则意味着生成的core文件统一命名叫core。
可由此以下命令修改此文件:
echo "1" > /proc/sys/kernel/core_uses_pid
[root@localhost log]# cat /proc/sys/kernel/core_uses_pid
1
再者注意,唯有超级客户才方可修改这三个表。/proc/sys/kernel/core_uses_pid能够决定产生的core文件的公文名中是不是增添pid作为增添,借使增多则文件内容为1,不然为0
core_pattern接受的是core文件名称的pattern,它含有别的字符串,何况用%作为转移符号生成一些标示符,为core文件名称出席特别含义。已定义的标识符有如下这一个:
%%:相当于%
%p:相当于<pid>
%u:相当于<uid>
%g:相当于<gid>
%s:也就是导致dump的功率信号的数字
%t:相当于dump的时间
%e:也等于施行文书的称号
%h:相当于hostname
除上述那些标识位外,还规定:
1、末尾的单个%能够直接删除;
2、%加上巳上述以外的任何字符,%和该字符都会被去除;
3、全数其余字符都作为日常字符参与名称中;
4、core文件的名称最大值为六十一个字节(包含'');
5、core_pattern中暗中同意的pattern为core;
6、为了维持包容性,通过安装core_uses_pid,能够在core文件的末尾加上%p;
7、pattern中得以满含路线音讯。

若果想让修改永远生效,则要求修改配置文件,如 .bash_profile、/etc/profile或/etc/security/limits.conf。

vi /etc/profile
ulimit -S -c 204800
ulimit -u 4096
ulimit -n 20480

测验产生与查看深入分析core文件
一个小方法来测验发生core文件
直白输入指令:kill -s SIGSEGV $$    $$为希望发生core文件的长河名
kill -9 pid也会发生以下类似文件
asterisk重启会在/tmp/下发生以下文件
-rw-------  1 root root 337735680 Aug 27 19:54 core.109-com1-2014-08-27T19:54:07 0800
[root@coreserv tmp]# gdb asterisk core.coreserv-2014-08-28T17:44:33 0800
gdb --core=core.12345(core dump文件名)或gdb exe名 core名 例如:gdb asterisk core文件
bt 查看程序运行到哪个地方,backtrace
file exe名 找exe位置
l 列出代码
where 显示在哪个地方down掉  GDB中键入where,就拜候到程序崩溃时货仓消息(当前函数以前的享有已调用函数的列表(包含这几天函数),gdb只显示这两天多少个)

暗中认可景况下,GCC在编写翻译时不会将调节和测量试验符号插入到变化的二进制代码中,因为如此会扩展可施行文件的轻重缓急。如若要求在编写翻译时生成调节和测量试验符号消息,能够采纳GCC的-g或然-ggdb选项。GCC在发出调节和测量试验符号时,一样选择了个别的思路,开荒人士能够经过在-g选项后附加数字1、2或3来钦点在代码中投入调节和测量试验音信的多少。暗中同意的等级是2(-g2),此时暴发的调试音讯蕴含扩张的符号表、行号、局地或外界变量音讯。等级3(-g3)包涵品级第22中学的全体调节和测量试验消息,以及源代码中定义的宏。品级1(-g1)不包罗部分变量和与行号有关的调节和测量试验音讯,由此只可以够用于回溯追踪和储藏室转储之用。回溯跟踪指的是监视程序在运维进程中的函数调用历史,仓库转储则是一种以不肯去观音院真面指标十六进制格式保存程序实施意况的方法,两个都以常事利用的调治花招。

有心人分析一下GDB给出的输出结果简单看出,程序是由于段错误而形成万分中止的,说明内部存款和储蓄器操作出了难点,具体产生难点的地点是在调用_IO_vfscanf_internal ( )的时候。为了获取尤其有价值的消息,能够选取GDB提供的想起追踪命令backtrace,实践结果如下:

(gdb) backtrace
#0 0×4008576b in _IO_vfscanf_internal () from /lib/libc.so.6
#1 0xbffff0c0 in ?? ()
#2 0×4008e0ba in scanf () from /lib/libc.so.6
#3 0×08048393 in main () at crash.c:11
#4 0×40042917 in __libc_start_main () from /lib/libc.so.6
跳过输出结果中的后面三行,从出口结果的第四行中简单看出,GDB已经将错误定位到crash.c中的第11行了。现在精心检查一下
(gdb) frame 3
#3 0×08048393 in main () at crash.c:11
11 scanf("%d", input);
第四行是main()函数的代码,而前几行都以系统代码

还有一个小问题,网上很少提到:被调试的程序必须和源码放在同一台机器上,才能用list命令列出源码,否则提示找不到。
[root@109-com1 tmp]# gdb asterisk core.109-com1-2014-12-09T09:52:26 0800
Loaded symbols for /lib64/libnss_dns.so.2
Core was generated by `/usr/sbin/asterisk -f -vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f528e49879a in _int_free () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6_5.3.x86_64 ncurses-libs-5.7-3.20090208.el6.x86_64
程序“调用堆栈”是当前函数之前的所有已调用函数的列表(包括当前函数)。每个函数及其变量都被分配了一个“帧”,最近调用的函数在 0 号帧中(“底部”帧)。要打印堆栈,发出命令 'bt'('backtrace' [回溯] 的缩写):
实际上,发出 'info locals' 命令时,gdb 会打印出当前帧中的局部变量,缺省情况下,这个帧中的函数就是被中断的函数(0 号帧)。可以使用命令 'frame' 打印当前帧。要查看 main 函数(在 1 号帧中)中的变量,可以发出 'frame 1' 切换到 1 号帧,然后发出 'info locals' 命令:
从下面可以看出函数的调用栈信息:clone()->start_thread()->......->_int_free(),由栈顶5到栈底0

(gdb) bt
#0  0x00007f528e49879a in _int_free () from /lib64/libc.so.6
#1  0x00007f5276acd3da in msrm_rm_ok_unit (msg_sn=65896) at chan_flt_comserver.c:11870
#2  0x00007f5276aefd08 in mec_udp_client_chan_pkg_recv (p=0x0) at chan_flt_comserver.c:19277
#3  0x00000000004c5654 in dummy_start (data=0x1b02a90) at utils.c:895
#4  0x00007f528ee8f9d1 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f528e508b5d in clone () from /lib64/libc.so.6
(gdb) where
#0  0x00007f528e49879a in _int_free () from /lib64/libc.so.6
#1  0x00007f5276acd3da in msrm_rm_ok_unit (msg_sn=65896) at chan_flt_comserver.c:11870
#2  0x00007f5276aefd08 in mec_udp_client_chan_pkg_recv (p=0x0) at chan_flt_comserver.c:19277
#3  0x00000000004c5654 in dummy_start (data=0x1b02a90) at utils.c:895
#4  0x00007f528ee8f9d1 in start_thread () from /lib64/libpthread.so.0
#5  0x00007f528e508b5d in clone () from /lib64/libc.so.6
(gdb) f
#0  0x00007f528e49879a in _int_free () from /lib64/libc.so.6
(gdb) info locals
No symbol table info available.
(gdb) f 2
#2  0x00007f5276aefd08 in mec_udp_client_chan_pkg_recv (p=0x0) at chan_flt_comserver.c:19277
19277                       msrm_rm_ok_unit(rsp_sn);
(gdb) info locals
thire_addr = {sin_family = 2, sin_port = 16796, sin_addr = {s_addr = 33728704}, sin_zero = "00000000000000"}
recv_buffer = "2000101h", '00' <repeats 3803 times>, "02", '00' <repeats 23 times>, "@", '00' <repeats 31 times>, "0200000060000000[000000|000000w000000n", '00' <repeats 19 times>, "@05020000000000300n00fR17700003000000000000000 0000fR1770000200376z216R177000066246I216R177", '00' <repeats 18 times>"260, ]x205R177000060;3423623771770000300ix205R17700000400000000000000a0000000000000024BL", '00' <repeats 29 times>, " 316O00000000000000000067010000t245O00000000003000000000000000205mB", '00' <repeats 13 times>...
recv_len = 8
rsp_sn = 65896
thire_addr_len = 16
__PRETTY_FUNCTION__ = "mec_udp_client_chan_pkg_recv"
(gdb) f 1        切换栈,用up与down,栈顶就是当前栈
#1  0x00007f5276acd3da in msrm_rm_ok_unit (msg_sn=65896) at chan_flt_comserver.c:11870
11870                       if(NULL != Msrm[msg_sn].pdatabuf) free(Msrm[msg_sn].pdatabuf);
(gdb) info locals    打印当前函数的局部变量与值
p_mec_send_task = 0x7f5200004210
__PRETTY_FUNCTION__ = "msrm_rm_ok_unit"
(gdb) info args        打印当前函数的参数名与值
msg_sn = 65896
(gdb) up
#2  0x00007f5276aefd08 in mec_udp_client_chan_pkg_recv (p=0x0) at chan_flt_comserver.c:19277
19277                       msrm_rm_ok_unit(rsp_sn);
(gdb) up
#3  0x00000000004c5654 in dummy_start (data=0x1b02a90) at utils.c:895
895             ret = a.start_routine(a.data);
(gdb) up
#4  0x00007f528ee8f9d1 in start_thread () from /lib64/libpthread.so.0

(gdb) frame 2
#2  0x00007f5276aefd08 in mec_udp_client_chan_pkg_recv (p=0x0) at chan_flt_comserver.c:19277
19277                       msrm_rm_ok_unit(rsp_sn);
(gdb) l        list: 列出当前位置之后的10行代码;list line_number: 列出line_number之后的十行代码
19272               if(recv_buffer[0] == '2')
19273               {
19274                   rsp_sn = CHARS4TOINT(recv_buffer 1);
19275                   if(0 != rsp_sn)
19276                   {
19277                       msrm_rm_ok_unit(rsp_sn);
19278                   }
19279                   else
19280                   {
19281                       mec_mantenance_refresh();
(gdb) info locals    列出当前函数的局部变量
thire_addr = {sin_family = 2, sin_port = 16796, sin_addr = {s_addr = 33728704}, sin_zero = "00000000000000"}
recv_buffer = "2000101h", '00' <repeats 3803 times>, "02", '00' <repeats 23 times>, "@", '00' <repeats 31 times>, "0200000060000000[000000|000000w000000n", '00' <repeats 19 times>, "@05020000000000300n00fR17700003000000000000000 0000fR1770000200376z216R177000066246I216R177", '00' <repeats 18 times>"260, ]x205R177000060;3423623771770000300ix205R17700000400000000000000a0000000000000024BL", '00' <repeats 29 times>, " 316O00000000000000000067010000t245O00000000003000000000000000205mB", '00' <repeats 13 times>...
recv_len = 8
rsp_sn = 65896
thire_addr_len = 16
__PRETTY_FUNCTION__ = "mec_udp_client_chan_pkg_recv"
(gdb) info frame
Stack level 2, frame at 0x7f5285785df0:
 rip = 0x7f5276aefd08 in mec_udp_client_chan_pkg_recv (chan_flt_comserver.c:19277); saved rip 0x4c5654
 called by frame at 0x7f5285785ec0, caller of frame at 0x7f5285784d80
 source language c.
 Arglist at 0x7f5285785de0, args: p=0x0
 Locals at 0x7f5285785de0, Previous frame's sp is 0x7f5285785df0
 Saved registers:
  rbx at 0x7f5285785dd8, rbp at 0x7f5285785de0, rip at 0x7f5285785de8
(gdb) frame 3
#3  0x00000000004c5654 in dummy_start (data=0x1b02a90) at utils.c:895
895             ret = a.start_routine(a.data);
(gdb) info f        打印当前栈层的详细信息
Stack level 3, frame at 0x7f5285785ec0:
 rip = 0x4c5654 in dummy_start (utils.c:895); saved rip 0x7f528ee8f9d1
 called by frame at 0x7f5285786000, caller of frame at 0x7f5285785df0
 source language c.
 Arglist at 0x7f5285785eb0, args: data=0x1b02a90
 Locals at 0x7f5285785eb0, Previous frame's sp is 0x7f5285785ec0
 Saved registers:
  rbp at 0x7f5285785eb0, rip at 0x7f5285785eb8

(gdb) help all

Command class: aliases

ni -- Step one instruction
rc -- Continue program being debugged but run it in reverse
rni -- Step backward one instruction
rsi -- Step backward exactly one instruction
si -- Step one instruction exactly
stepping -- Specify single-stepping behavior at a tracepoint
tp -- Set a tracepoint at specified line or function
tty -- Set terminal for future runs of program being debugged
where -- Print backtrace of all stack frames
ws -- Specify single-stepping behavior at a tracepoint

Command class: breakpoints

awatch -- Set a watchpoint for an expression
break -- Set breakpoint at specified line or function

Command class: data

append -- Append target code/data to a local file
display -- Print value of expression EXP each time the program stops
dump -- Dump target code/data to a local file
dump binary -- Write target code/data to a raw binary file
dump binary memory -- Write contents of memory to a raw binary file

Command class: files

add-symbol-file -- Load symbols from FILE
add-symbol-file-from-memory -- Load the symbols out of memory from a dynamically loaded object file
cd -- Set working directory to DIR for debugger and program being debugged
list -- List specified function or line

 

core文件创制在哪些岗位
在经过当前工作目录的下创办。平常与程序在一直以来的路子下。但假设程序中调用了chdir函数,则有非常大希望改造了当前职业目录。那时core文件创造在chdir钦赐的路线下。有众多前后相继崩溃了,大家却找不到core文件放在怎样职位。和chdir函数就有涉及。当然程序崩溃了不自然都发出core文件。
如曾几何时候不发出core文件
在下列条件下不发出core文件:
( a )进度是安装-客商-ID,况兼前段时间客户不用程序文件的主人;
( b )进程是安装-组-ID,並且近年来客商毫无该程序文件的组全体者;
( c )客商未有写当前专门的学业目录的许可权;
( d )文件太大。core文件的许可权(假定该文件在此以前并不设有)日常是顾客读/写,组读和其余读。

一、要确认保证贮存Coredump的目录存在且经过对该目录有写权限。寄放Coredump的目录即经过的当前目录,常常即是那时产生指令运维该进程时所在的目录。但假若是因此脚本运转,则脚本或然会修改当前目录,那时进度真正的当前目录就能够与那时候实行脚本所在目录分歧。那时能够查阅”/proc/<进度pid>/cwd“符号链接的指标来鲜明进度真正的当前目录地址。通过系统服务运营的经过也可经过这一措施查看。
二、若程序调用了seteuid()/setegid()改动了经过的实用客户或组,则在暗许境况下系统不会为这个经过生成Coredump。相当多服务程序都会调用seteuid(),如MySQL,不论你用什么样客户运维mysqld_safe运转MySQL,mysqld进行的有用顾客一直是msyql顾客。若是您那时是以客户A运营了某些程序,但在ps里看看的这几个顺序的顾客却是B的话,那么那么些进程就是调用了seteuid了。为了能够让那一个经过生成core dump,供给将/proc/sys/fs /suid_dumpable文件的内容改为1(常常暗许是0)。
三、要设置丰硕大的Core文件大小限制了。程序崩溃时生成的Core文件大小即为程序运维时占用的内部存款和储蓄器大小。但顺序崩溃时的行为不得按平时时的作为来打量,比方缓冲区溢出等错误恐怕形成旅舍被破坏,由此平常会冒出某些变量的值被更动成一塌糊涂的,然后程序用那个尺寸去报名内部存款和储蓄器就大概导致程序比平常时多占用比很多内部存款和储蓄器。因而无论程序不荒谬化运营时占用的内存多么少,要确定保证生成Core文件依旧将大小限制设为unlimited为好。

什么样动静下发出core文件

     当大家的顺序崩溃时,内核有比异常的大大概把该程序当前内部存款和储蓄器映射到core文件里,方便程序猿找到程序出现难点的地方。最常出现的,大约具备C程序员都冒出过的荒唐正是“段错误”了。也是最难查出标题原因的两个谬误。上面大家就针对“段错误”来深入分析core文件的发生、以及大家什么样接纳core文件找到出现崩溃的地点。当一个程序崩溃时,在经过当前工作目录的core文件中复制了该进程的囤积图像。core文件仅仅是一个内部存储器映象(同期丰裕调节和测验新闻),首若是用来调治的。

当程序接收到以下UNIX能量信号会时有发生core文件:

名字

说明

ANSI C  POSIX.1

SVR4  4.3 BSD

缺省动作

SIGABRT

异常终止(abort)

  .       .

  .      .

终止w/core

SIGBUS

硬件故障

          .

  .      .

终止w/core

SIGEMT

硬件故障

 

  .      .

终止w/core

SIGFPE

算术异常

  .       .

  .      .

终止w/core

SIGILL

非法硬件指令

  .       .

  .      .

终止w/core

SIGIOT

硬件故障

 

  .      .

终止w/core

SIGQUIT

终端退出符

          .

  .      .

终止w/core

SIGSEGV

无效存储访问

  .       .

  .      .

终止w/core

SIGSYS

无效系统调用

 

  .      .

终止w/core

SIGTRAP

硬件故障

 

  .      .

终止w/core

SIGXCPU

超过CPU限制(setrlimit)

 

  .      .

终止w/core

SIGXFSZ

超过文件长度限制(setrlimit)

 

  .      .

终止w/core

在系统默许动作列,“终止w/core”表示在进程当前职业目录的core文件中复制了该进程的存款和储蓄图像(该文件名叫core,由此能够见见这种意义非常久此前正是UNIX功效的一部分)。大大多UNIX调节和测量检验程序都利用core文件以检查进度在停止时的景况。core文件的发生不是POSIX.1所属部分,而是相当多UNIX版本的落到实处特征。UNIX第6版未有检查标准(a)和(b),并且其源代码中带有如下表明:“要是你正在寻找爱戴功率信号,那么当设置-用户-ID命令施行时,将只怕产生大批量的这种频域信号”。4.3

  • BSD发生名称叫core.prog的文书,当中prog是被实行的程序名的前拾伍个字符。它对core文件予以了某种标记,所以是一种革新特征。表中“硬件故障”对应于贯彻定义的硬件故障。那几个名字中有过多取自UNIX最早在DP-11上的贯彻。请查看你所运用的体系的手册,以切合地规定这个时限信号对应于如何不当类型。

下边比较详细地证实那些功率信号。

• SIGABRT 调用abort函数时发生此时限信号。进程极其终止。

• SIGBUS  提醒一个贯彻定义的硬件故障。

• SIGEMT  提醒一个兑现定义的硬件故障。

EMT这一名字来自PDP-11的emulator trap 指令。

• SIGFPE  此实信号表示一个算术运算极度,比方除以0,浮点溢出等。

• SIGILL  此复信号提醒进度已进行一条地下硬件指令。

4.3BSD由abort函数产生此频域信号。SIGABRT今后被用于此。

• SIGIOT  那提示两个实现定义的硬件故障。

IOT这几个名字来自于PDP-11对于输入/输出TRAP(input/output TRAP)指令的缩写。系统V的开始时期版本,由abort函数发生此功率信号。SIGABRT未来被用来此。

• SIGQUIT 当客户在巅峰上按退出键(日常选用Ctrl-/)时,发生此实信号,并送至前台进

程组中的全体过程。此非功率信号不止终止前台进度组(如SIGINT所做的那样),同一时间发生贰个core文件。

• SIGSEGV 提示进程展开了一次不行的积攒访谈。

名字SEGV表示“段违例(segmentation violation)”。

• SIGSYS  提示三个不算的系统调用。由于某种未知原因,进程实施了一条系统调用指令,

但其提醒系统调用类型的参数却是无效的。

• SIGTRAP 提醒几个落到实处定义的硬件故障。

此信号名来自于PDP-11的TRAP指令。

• SIGXCPU SV景逸SUV4和4.3 BSD扶助财富限制的概念。若是经过超过了其软C P U时间范围,则发出此信号。

• SIGXFSZ 如若经过当先了其软文件长度限制,则SVHaval4和4.3 BSD发出此随机信号。

摘自《UNIX景况高端编制程序》第10章 非确定性信号。

在软件开拓的经过中,无论如何努力,bug大约都以必不可缺的。当有些bug发生时,该进度会时有发生coredump文件。通过这些coredump文件,开拓人士能够找到bug的由来。不过coredump的产生,大都以因为程序crash了。

  1. 死锁
       有个别bug是不会导致进程crash的,比如死锁——那时,程序已经不正规了,可是却从没coredump发生。假设条件又不允许gdb调节和测量检验,难道大家就力不胜任了啊?针对这种情景,平日景色下,对于那样的进度,能够行使watchdog监控它们,当发掘这一个进度相当长日子尚无立异其heartbeat时,能够给这一个经过发送能够导致其爆发coredump的实信号。依据linux的数字信号暗中同意的管理作为,SIGQUIT,SIGABRT, SIGFPE和SIGSEGV都足以让该进程爆发coredump文件。那样我们得以因而coredump来获知死锁是还是不是发生。当然,假使经过增添了那几个非信号的管理函数,那么就不会时有爆发coredump了。
    2.获得钦点地方快速照相:
       还应该有一种情景,进度并不曾死锁恐怕block在有个别地点,不过大家须要在有些钦赐地方进行调剂,获取有些变量或许其余消息。不过,有极大希望是顾客景况仍然生产情形,差别意大家开展长日子的检验。那么,我们就要求通过coredump来收获过程在运作到该点时的快照。
    其有的时候候,能够行使gdb来发入手工业爆发coredump。在attach上那个进度时,在钦赐地点打上断点,当断点触发时,使用gdb的指令gcore,能够即时爆发一个coredump。这样,大家就拿到了这一个岗位的历程快速照相。1. 欲查看八线程程序中负有线程的调用栈音信====================================
         gdb attach xxx
         set height 0
          thread apply all bt
          detach
          q
  2. CPU占用率过高难点分析方法

    shell下推行:ps -eLfP 寻找cpu占用率高的线程
    UID        PID  PPID   LWP PSR  C NLWP STIME TTY          TIME
    root      1431  1270  1751   5 90   64 Dec24 ?        00:00:00
                          ^^^^  ^^ ^^
                        thread core cpurate
    使用gdb:
    gdb attach 1431        <==== 登陆cpu占用率高的进度
    set height 0
    i thread               <==== 打字与印刷该进度的全数线程
    找到 : LWP 1751 线程
    17 Thread 855356656 (LWP 1751)  0x2ac30994 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
    ^^                   ^^^^^^^^
    打出cpu占用率高的 任务的调用栈:
    thread 17   <============  切换成该线

[root@109-com1 ~]# gstack 428
#0  0x00007fdca018f2f8 in poll () from /lib64/libc.so.6
#1  0x00007fdca089cdcd in main ()
[root@109-com1 ~]# pstack 428
#0  0x00007fdca018f2f8 in poll () from /lib64/libc.so.6
#1  0x00007fdca089cdcd in main ()

yum install gdb
gstack 30222
pstack 30222
ps  -eLo pid,lwp,pcpu | grep 30222

[root@109-com1 ~]# ps  -eLo pid,lwp,pcpu | grep 11167

$ gdb /path/to/rsyslogd
$ core /core.1234
$ info thread
$ thread apply all bt full
$ q # quits gdb

 

 

 

 

truss和strace用来 追踪三个经过的连串调用或时域信号发生的情形,而 ltrace用来 追踪进度调用库函数的状态。truss是开始的一段时代为System V Enclave4费用的调节和测量检验程序,包含Aix、FreeBSD在内的许多Unix系统都自带了那个工具;而strace最先是为SunOS系统一编写制的,ltrace最先出现在GNU/Debian Linux中。那四个工具今后也已被移植到了大多Unix系统中,大相当多Linux发行版都自带了strace和ltrace,而FreeBSD也可透过Ports安装它们。

 

 

ltrace is a program that simply runs the specified command until it exits.
It intercepts and records
the dynamic library calls which are called by the executed process
and
the signals which are received by that process

Its use is very similar to strace

intercepts    vt. 拦截;截断;窃听

 

 

[root@localhost ~]# rpm -qf /usr/bin/strace
strace-4.5.19-1.17.el6.x86_64
[root@localhost ~]# rpm -qf /usr/bin/ltrace
ltrace-0.5-23.45svn.el6.x86_64

truss, strace, ltrace是八个常见的调度工具。
他俩有四个最常用的参数
-f: 除了追踪当前进度外,还追踪子进度
-o: 将出口消息写到文件file中
-p pid: 绑定一个由PID对应的进度

Example:
truss -o ls.txt ls -al
strace -f -o vi.txt vi
ltrace -p 123

本文由澳门新浦京娱乐场网站发布于澳门新浦京娱乐场网站,转载请注明出处:澳门新浦京娱乐场网站:linux包之gdb之gdb命令与