首页 > 代码库 > 用core dump来调试程序段错误

用core dump来调试程序段错误

2024-07-13 22:07:36   225人阅读

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

 

1.在一般Linux系统中，默认是不会产生core dump文件的。通过ulimit -c来查看core dump文件的大小，一般开始是0。
    可以设置core文件大小，ulimit -c 1024(kbytes单位)或者ulimit -c unlimited。（注: 使用-c unlimited不限制core文件大小）
2.生成core文件: $ sudo  sh -c "ulimit -c unlimited; ./main_arm" # main_arm 是可执行文件名。
3.记得在编译时加上 -g 方便调试,注意不要加上优化选项 -Os(或者-O0 -O1 ....)
4.用gdb查看core文件:
    gdb [exec file] [core file]
    如：gdb main_arm core
    在进入gdb后, 用 bt 或 where 命令查看backtrace以检查发生程序运行到哪里, 来定位core dump的文件行.
5.举例：

[html] view plaincopy
 
  1. 一个程序cmm_test_tool在运行的时候发生了错误，并生成了一个core文件，如下：  
  2.   
  3.     -rw-r–r– 1 root cmm_test_tool.c  
  4.   
  5.     -rw-r–r– 1 root cmm_test_tool.o  
  6.   
  7.     -rwxr-xr-x 1 root cmm_test_tool  
  8.   
  9.     -rw——- 1 root core.19344  
  10.   
  11.     -rw——- 1 root core.19351  
  12.   
  13.     -rw-r–r– 1 root cmm_test_tool.cfg  
  14.   
  15.     -rw-r–r– 1 root cmm_test_tool.res  
  16.   
  17.     -rw-r–r– 1 root cmm_test_tool.log  
  18.   
  19.     [root@AUTOTEST_SIM2 mam2cm]#  
  20.   
  21. 就可以利用命令gdb进行查找，参数一是应用程序的名称，参数二是core文件，运行  
  22.   
  23. gdb cmm_test_tool core.19344结果如下：  
  24.   
  25.     [root@AUTOTEST_SIM2 mam2cm]# gdb cmm_test_tool core.19344  
  26.   
  27.     GNU gdb Red Hat Linux (5.2.1-4)  
  28.   
  29.     Copyright 2002 Free Software Foundation, Inc.  
  30.   
  31.     GDB is free software, covered by the GNU General Public License, and you are  
  32.   
  33.     welcome to change it and/or distribute copies of it under certain conditions.  
  34.   
  35.     Type “show copying” to see the conditions.  
  36.   
  37.     There is absolutely no warranty for GDB. Type “show warranty” for details.  
  38.   
  39.     This GDB was configured as “i386-redhat-linux”…  
  40.   
  41.     Core was generated by `./cmm_test_tool’.  
  42.   
  43.     Program terminated with signal 11, Segmentation fault.  
  44.   
  45.     Reading symbols from /lib/i686/libpthread.so.0…done.  
  46.   
  47.     Loaded symbols for /lib/i686/libpthread.so.0  
  48.   
  49.     Reading symbols from /lib/i686/libm.so.6…done.  
  50.   
  51.     Loaded symbols for /lib/i686/libm.so.6  
  52.   
  53.     Reading symbols from /usr/lib/libz.so.1…done.  
  54.   
  55.     Loaded symbols for /usr/lib/libz.so.1  
  56.   
  57.     Reading symbols from /usr/lib/libstdc++.so.5…done.  
  58.   
  59.     Loaded symbols for /usr/lib/libstdc++.so.5  
  60.   
  61.     Reading symbols from /lib/i686/libc.so.6…done.  
  62.   
  63.     Loaded symbols for /lib/i686/libc.so.6  
  64.   
  65.     Reading symbols from /lib/libgcc_s.so.1…done.  
  66.   
  67.     Loaded symbols for /lib/libgcc_s.so.1  
  68.   
  69.     Reading symbols from /lib/ld-linux.so.2…done.  
  70.   
  71.     Loaded symbols for /lib/ld-linux.so.2  
  72.   
  73.     Reading symbols from /lib/libnss_files.so.2…done.  
  74.   
  75.     Loaded symbols for /lib/libnss_files.so.2  
  76.   
  77.     #0 0×4202cec1 in __strtoul_internal () from /lib/i686/libc.so.6  
  78.   
  79.     (gdb)  
  80.   
  81. 进入gdb提示符，输入where，找到错误发生的位置和堆栈，如下：  
  82.   
  83.     (gdb) where  
  84.   
  85.     #0 0×4202cec1 in __strtoul_internal () from /lib/i686/libc.so.6  
  86.   
  87.     #1 0×4202d4e7 in strtoul () from /lib/i686/libc.so.6  
  88.   
  89.     #2 0×0804b4da in GetMaxIDFromDB (get_type=2, max_id=0×806fd20) at cmm_test_tool.c:788  
  90.   
  91.     #3 0×0804b9d7 in ConstrctVODProgram (vod_program=0×40345bdc) at cmm_test_tool.c:946  
  92.   
  93.     #4 0×0804a2f4 in TVRequestThread (arg=0×0) at cmm_test_tool.c:372  
  94.   
  95.     #5 0×40021941 in pthread_start_thread () from /lib/i686/libpthread.so.0  
  96.   
  97.     (gdb)  

至此，可以看出文件出错的位置是函数 GetMaxIDFromDB ，两个参数分别是2和0×806fd20，这个函数位于源代码的788行，基于此，我们就可以有针对性的找到问题的根源，并加以解决


联系
我们