gdb my experience

最新推荐文章于 2024-12-19 15:03:00 发布

原创最新推荐文章于 2024-12-19 15:03:00 发布 · 709 阅读

0 ·

CC 4.0 BY-SA版权

c-c++_gdb_etc 专栏收录该内容

37 篇文章

订阅专栏

本文介绍使用GDB进行程序调试的方法，包括设置条件断点、为断点定义运行命令、调试运行中的程序等高级技巧，并详细讲解如何利用core dump进行崩溃问题定位。

1, 条件断点
(gdb) br EKMemory.cpp:ekmalloc if tmpsize == 4760
或者
(gdb) br EKMemory.cpp:29 if tmpsize == 4760

(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0041b42e in ekmalloc at src/EKLibrary/EKMemory.cpp:25 stop only if tmpsize == 4760

2，为停止点设定运行命令
br EKMemory.cpp:29 if tmpsize == 4760
commands
bt
continue
end

实例：
(gdb) br EKMemory.cpp:29 if tmpsize == 4760
Breakpoint 1 at 0x41b44a: file src/EKLibrary/EKMemory.cpp, line 29.
(gdb) commands
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>bt
>continue
>end
(gdb) c
Continuing.

Breakpoint 1, ekmalloc (size=4760) at src/EKLibrary/EKMemory.cpp:29
29 src/EKLibrary/EKMemory.cpp: No such file or directory.
in src/EKLibrary/EKMemory.cpp
#0 ekmalloc (size=4760) at src/EKLibrary/EKMemory.cpp:29
#1 0x0041b520 in ekioh::EKMemory::alloc (size=4760) at src/EKLibrary/EKMemory.cpp:169
#2 0x0041b5ac in operator new[] (size=4760) at src/EKLibrary/EKMemory.cpp:151
#3 0x00497f0e in ekioh::KreaTvGfxPixMap::create (width=14, height=85) at src/Platform/Motorola/KreaTvGfx/KreaTvGfxPixMap.cpp:161
#4 0x00499d14 in ekioh::KreaTvGfxPlatform::createPixMap (this=0x7be854c0, width=14, height=85, bpp=32 ' ')
at src/Platform/Motorola/KreaTvGfx/KreaTvGfxPlatform.cpp:150
#5 0x004434dc in ekioh::EKGContext::createPixMap (width=14, height=85, bpp=32 ' ', accelerated=false) at src/EKLibrary/Graphics/EKGContext.cpp:291
#6 0x2a722e1c in WebCore::ImageSource::createFrameAtIndex () from /usr/lib/libekioh_adapt_webkit525-kreatvgfx.so
#7 0x2a4a9ea0 in WebCore::BitmapImage::cacheFrame () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#8 0x2a4aa996 in WebCore::BitmapImage::frameAtIndex () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#9 0x2a4abbb0 in WebCore::BitmapImage::nativeImageForCurrentFrame () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#10 0x2a4c5062 in WebCore::Image::drawTiled () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#11 0x2a4bef74 in WebCore::GraphicsContext::drawTiledImage () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#12 0x2a54421c in WebCore::RenderBox::paintBackgroundExtended () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#13 0x2a5395cc in WebCore::RenderBox::paintBackground () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#14 0x2a5396a2 in WebCore::RenderBox::paintBackgrounds () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#15 0x2a5453da in WebCore::RenderBox::paintBoxDecorations () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#16 0x2a5305fc in WebCore::RenderBlock::paintObject () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#17 0x2a52a566 in WebCore::RenderBlock::paint () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#18 0x2a57669a in WebCore::RenderLayer::paintLayer () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#19 0x2a576cd0 in WebCore::RenderLayer::paintLayer () from /usr/lib/libekioh_webcore_webkit525-kreatvgfx.so
#20 0x2ce1a510 in ?? ()
#21 0x2ce1a510 in ?? ()
Previous frame identical to this frame (corrupt stack?)

3，调试运行中程序
gdb -p PID
(gdb) breakpoints EKMemory.cpp:29 if tmpsize == 4760
(gdb) c

4 gdb 查看core dump ；

4.1. 前言:
有的程序可以通过编译, 但在运行时会出现Segment fault(段错误). 这通常都是指针错误引起的.
但这不像编译错误一样会提示到文件->行, 而是没有任何信息, 使得我们的调试变得困难起来.

4.2. gdb:
有一种办法是, 我们用gdb的step, 一步一步寻找.
这放在短小的代码中是可行的, 但要让你step一个上万行的代码, 我想你会从此厌恶程序员这个名字, 而把他叫做调试员.
我们还有更好的办法, 这就是core file.

4.3. ulimit:
如果想让系统在信号中断造成的错误时产生core文件, 我们需要在shell中按如下设置:
#设置core大小为无限
ulimit -c unlimited
#设置文件大小为无限
ulimit unlimited

这些需要有root权限, 在ubuntu下每次重新打开中断都需要重新输入上面的第一条命令, 来设置core大小为无限.

4.4. 用gdb查看core文件:
下面我们可以在发生运行时信号引起的错误时发生core dump了.
发生core dump之后, 用gdb进行查看core文件的内容, 以定位文件中引发core dump的行.
gdb [exec file] [core file]
如:
gdb ./test test.core
在进入gdb后, 用bt命令查看backtrace以检查发生程序运行到哪里, 来定位core dump的文件->行.

4.5. 用gdb实时观察某进程crash信息
启动进程
gdb -p PID
c
运行进程至crash
gdb会显示 crash信息
bt

5， gdb used on kreatv：

his is a tip about how to use gdb to check the crash bug:

5.1 . add "kreatv-tool-gdb" to bootimage
5.2. use kernel+nfs to boot up the box.
5.2.1 copy the execute file and .so lib into rootdisk's related position.
[leo@leo dlnamediacontroller]$ sudo cp st40/dlnamediacontroller /opt/nfs/rootdisk/usr/bin/dlnamediacontroller
[leo@leo dlnamediacontroller]$ pwd
/mnt/sda5/mot_develop/BRASSICA/platform/dlnamediacontroller

5.3. update the rootdisk/usr/bin/start_platform.sh to enable the core dump.
export COREDUMP_ENABLED=yes

5.4. when crash happens, core dump files are stored in the box's / directory. For example core.1167 which means the core dump file is created by the process pid 1167 5. telnet to the box and use gdb to check the core dump. For example, if the streamer crash and the pid is 574, run gdb like this:

The following can use box or PC. It is better run in box which need add "kreatv-tool-gdb" to bootimage.
# gdb /usr/bin/streamer core.574

5.6. If you are luck, you can see the streamercrashat which function and which line.

5.7. Most of time, you are not luck, you only can see some information like this:
#0 0x298ae0a4 in ?? ()
(gdb)bt
#0 0x298ae0a4 in ?? ()
#1 0x298af5a0 in ?? ()
This is because most of our binary and library are strippedbefore copying the the rootdisk.
Replacing the binary or library in the rootdisk with the original one built from branch and test again! Then you can see the detail function name.

It is proved very useful to fix some kinds of crash bug.

How can we crash process or box?
assert(1==0); will trige it.
int a = 1/0; will trige it.
char *abcd;
memcpy(abcd, "12345678",8); will trige it.

How to analyze core dump
• Run gdb in box
• or Run arm-kreatel-linux-gnu-gdb in PC
• Command example
– #xxx_gdb /usr/bin/streamer -c /tmp/core.dump
– #bt

Readme:
a, kreatv-tool-gdb only decide whether you can telnet box,and gdb on box.

example：

/# gdb /usr/applications/ekioh/ekioh core.526
GNU gdb 6.5-ST-1.0-ST40 [build Jul 2 2009]
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sh4-motorola-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/libVirtualDisplay.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libVirtualDisplay.so

Loaded symbols for usr/browser/plugins/libmotorolatoi.so
Got object file from memory but can't read symbols: File format not recognized.

Core was generated by `/usr/applications/ekioh/ekioh --cache 0 --url http://192.168.5.215'.
Program terminated with signal 7, Bus error.
#0 0x29f3224c in KJS::Bindings::Instance::setValueOfField () from /usr/lib/libjavascriptcore.so

(gdb) bt
#0 0x29f3224c in KJS::Bindings::Instance::setValueOfField () from /usr/lib/libjavascriptcore.so
#1 0x29919512 in ekioh::GTKSocketCollection::callback (source=<value optimized out>, condition=2076097000, data=0x443b50)
at src/Platform/GTK/GTKSocketCollection.cpp:255
#2 0x2a5ebbf2 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0
#3 0x2a5ecdb2 in g_main_add_poll () from /usr/lib/libglib-1.2.so.0
#4 0x2a60875c in ?? () from /usr/lib/libglib-1.2.so.0
#5 0x2a60875c in ?? () from /usr/lib/libglib-1.2.so.0
Previous frame identical to this frame (corrupt stack?)

(gdb) q
/ # exit
Connection closed by foreign host.
[root@localhost infocast]#