如何根据core文件中错误地址定位程序
在Unix系统下，应用程序崩溃，一般会产生core文件，如何根据core文件查找问题的所在，并做相应的分析和调试，是非常重要的，本文对此做简单介绍。
例如，一个程序cmm_test_tool在运行的时候发生了错误，并生成了一个core文件，如下：
-rw-r–r– 1 root cmm_test_tool.c
-rw-r–r– 1 root
cmm_test_tool.o
-rwxr-xr-x 1 root cmm_test_tool
-rw——- 1 root
core.19344
-rw——- 1 root core.19351
-rw-r–r– 1 root
cmm_test_tool.cfg
-rw-r–r– 1 root cmm_test_tool.res
-rw-r–r– 1 root
cmm_test_tool.log
[root@AUTOTEST_SIM2 mam2cm]#
就可以利用命令gdb进行查找，参数一是应用程序的名称，参数二是core文件，运行
gdb
cmm_test_tool core.19344结果如下：
[root@AUTOTEST_SIM2 mam2cm]# gdb cmm_test_tool core.19344
GNU gdb Red Hat
Linux (5.2.1-4)
Copyright 2002 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
“i386-redhat-linux”…
Core was generated by `./cmm_test_tool’.
Program
terminated with signal 11, Segmentation fault.
Reading symbols from
/lib/i686/libpthread.so.0…done.
Loaded symbols for
/lib/i686/libpthread.so.0
Reading symbols from
/lib/i686/libm.so.6…done.
Loaded symbols for /lib/i686/libm.so.6
Reading
symbols from /usr/lib/libz.so.1…done.
Loaded symbols for
/usr/lib/libz.so.1
Reading symbols from
/usr/lib/libstdc++.so.5…done.
Loaded symbols for
/usr/lib/libstdc++.so.5
Reading symbols from
/lib/i686/libc.so.6…done.
Loaded symbols for /lib/i686/libc.so.6
Reading
symbols from /lib/libgcc_s.so.1…done.
Loaded symbols for
/lib/libgcc_s.so.1
Reading symbols from /lib/ld-linux.so.2…done.
Loaded
symbols for /lib/ld-linux.so.2
Reading symbols from
/lib/libnss_files.so.2…done.
Loaded symbols for /lib/libnss_files.so.2
#0
0×4202cec1 in __strtoul_internal () from
/lib/i686/libc.so.6
(gdb)
进入gdb提示符，输入where，找到错误发生的位置和堆栈，如下：
(gdb) where
#0 0×4202cec1 in __strtoul_internal () from
/lib/i686/libc.so.6
#1 0×4202d4e7 in strtoul () from
/lib/i686/libc.so.6
#2 0×0804b4da in GetMaxIDFromDB (get_type=2,
max_id=0×806fd20) at cmm_test_tool.c:788
#3 0×0804b9d7 in ConstrctVODProgram
(vod_program=0×40345bdc) at cmm_test_tool.c:946
#4 0×0804a2f4 in
TVRequestThread (arg=0×0) at cmm_test_tool.c:372
#5 0×40021941 in
pthread_start_thread () from /lib/i686/libpthread.so.0
(gdb)
至此，可以看出文件出错的位置是函数 GetMaxIDFromDB
，两个参数分别是2和0×806fd20，这个函数位于源代码的788行，基于此，我们就可以有针对性的找到问题的根源，并加以解决。
什么啊。。
The problem that no `core' file is created on a segmentation fault; Locate errors in the source with GDB and `core' filesLinux 程序在遇到段错误(常见的是由非法访问内存引起)的时候会产生 core 文件，如果这个程序包含调试信息(编译的时候加 -g 选项)，那么使用 gdb 读取这个 core 文件可以快速定位出错的源代码。原来在某软件公司实习的时候(用 RedHat Enterprise Linux)觉得这样非常方便查错，但我自己用的 Debian GNU/Linux 却默认不生成这个文件。
检查以后发现原因是 core 文件最大尺寸(用 ulimit -c 查看)是 0，把它设置成非 0 值就可以了，如:
ulimit -c 2048(设置 core 文件最大尺寸为 2048 blocks，1block=512bytes，因此这里设置的其实是 1MiB)
ulimit -c unlimited(不限 core 文件尺寸)
附:用 gdb 根据 core dump 文件定位错误的办法。
用这个程序作一个测试:
int foo (int *p)
{
return *p;
}
main()
{
foo (0);
}
derek@dli: /tmp $ gcc -g a.c
derek@dli: /tmp $ ./a.out
段错误 (core dumped)
derek@dli: /tmp $ gdb ./a.out -c core
(这里略去约十行其他信息)
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0 0x0804834a in foo (p=0x0) at a.c:3
3 return *p;
如果再输入一条命令 bt，就可以看得清清楚楚错误是在什么时机产生的:
(gdb) bt
#0 0x0804834a in foo (p=0x0) at a.c:3
#1 0x0804836b in main () at a.c:8
不能有比这更清楚的错误信息了!如果是在 Windows 下，就老老实实 Trace and Step 吧。
答：ulimit -c 2048(设置 core 文件最大尺寸为 2048 blocks，1block=512bytes，因此这里设置的其实是 1MiB)ulimit -c unlimited(不限 core 文件尺寸)附:用 gdb 根据 core dump 文件定位错误的办法。用这个程序作一个测试:int foo (int *p){ return *p;} main(){ foo (0);} derek@dli: /tmp ...
答：一般这种情况都是因为数组越界访问，空指针或是野指针读写造成的。程序小的话还比较好办，对着源代码仔细检查就能解决。但是对于代码量较大的程序，里边包含N多函数调用，N多数组指针访问，这时想定位问题就不是很容易了(此时牛人依然可以通过在适当位置打printf加二分查找的方式迅速定位:P)。懒人的话还是...
答：用gdb查看core 文件，可以直接定位到出错的位置的。1，在编译程序时候gcc 增加 -g选项。2，在终端中设置core文件的大小不受限制:ulimit -c unlimited 3,出问题后,输入gdb ./test core.4，GDB中输入bt ,就可以查看程序崩溃的代码位置和堆栈调用情况。
答：[root@AUTOTEST_SIM2 mam2cm]就可以利用命令gdb进行查找，参数一是应用程序的名称，参数二是core文件，运行 gdb cmm_test_tool core.19344结果如下：[root@AUTOTEST_SIM2 mam2cm]# gdb cmm_test_tool core.19344 GNU gdb Red Hat Linux (5.2.1-4)Copyright 2002 Free Software Foundation, Inc....
答：在处理Core异常问题时，我们首先需要定位问题出现的位置。可以使用调试工具对程序进行调试，通过观察代码的执行路径、变量值等信息，定位问题发生的位置。一旦定位问题，我们就需要重新设计程序或者修复错误代码。在解决Core异常问题时，需要注意保护程序的敏感信息，以防止信息泄露。此外，及时备份数据也是一种有效...
答：1、在使用CoreLocation前需要调用如下函数【iOS 8专用】：iOS 8对定位进行了一些修改，其中包括定位授权的方法，CLLocationManager增加了下面的两个方法：（1）始终允许访问位置信息 - (void)requestAlwaysAuthorization;（2）使用应用程序期间允许访问位置数据 - (void)requestWhenInUseAuthorization;示例如下：...
答：3、CORE文件。数据库相关进程在运行过程中可能会因为各种意外情况导致数据库崩溃 （Coredump），而崩溃时产生的core文件对于迅速定位程序崩溃的原因及位置非常重要。如果进程运行时出现Coredump现象，建议立即收集core文件便于分析、定位故障。对性能有一定的影响，尤其是进程频繁异常时对性能的影响更大。core文件...
答：1、使用爱思助手：在爱思助手的工具箱中点击“虚拟定位”功能，点击“修改虚拟定位”按钮即可立即定位，也可以打开iOS默认地图查看定位是否成功。如果不想再定位，想要恢复原状，点击“还原真实坐标”即可。2、使用Xcode：在Xcode中新建一个项目，创建一个gpx文件，找到项目中的Location.gpx文件，修改gpx文件...
答：方法/步骤 创建工程项目和视图控制器 1、创建一个Sing View Application工程项目；2、为项目命名，生成工程文件。为适配iOS8需要配置info.plist文件 添加2行：NSLocationAlwaysUsageDescription 设为Boolean类型 = YES NSLocationWhenInUseUsageDescription 设为Boolean类型 = YES 引入CoreLocation框架 包含头...
答：下面我们可以在发生运行时信号引起的错误时发生core dump了.发生core dump之后, 用gdb进行查看core文件的内容, 以定位文件中引发core dump的行.gdb [exec file] [core file]如:gdb ./test test.core 在进入gdb后, 用bt命令查看backtrace以检查发生程序运行到哪里, 来定位core dump的文件->行.如何...
