gdbmyexperience

4 gdb 查看core dump &＃xff1b;

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&＃xff0c; gdb used on kreatv&＃xff1a;

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&＃43;nfs to boot up the box.
5.2.1 copy the execute file and .so lib into rootdisk&＃39;s related position. 
[leo&＃64;leo dlnamediacontroller]$ sudo cp st40/dlnamediacontroller /opt/nfs/rootdisk/usr/bin/dlnamediacontroller
[leo&＃64;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&＃61;yes


5.4. when crash happens, core dump files are stored in the box&＃39;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&＃61;&＃61;0);  will trige it.
int a &＃61; 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&＃xff1a; 

 /# 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&＃39;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&＃39;t read symbols: File format not recognized.

Core was generated by &＃96;/usr/applications/ekioh/ekioh --cache 0 --url http://192.168.5.215&＃39;.
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&＃61;, condition&＃61;2076097000, data&＃61;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&＃64;localhost infocast]#

6&＃xff0c; 如何查看&＃xff1f;  的内存地址空间&＃xff1f;&＃xff1f;&＃xff1f;