Ⅰ linux core 怎么打开
core文件是由应用程序收到系统信号后崩溃产生的，该文件中记录了程序崩溃的原因(例如收到那种信号)，调用堆栈和崩溃时的内存及变量值等等的信息。打开core文件与编译时使用的编译器有关，但绝大多数linux程序是使用gcc编译器编译的，因此可使用对应gdb调试器打开，命令格式如下：$ gdb 应用程序文件名 core文件名举例：$ gdb /usr/bin/gedit ~/core —— 查看由gedit崩溃产生的core文件(gdb) bt —— 或者backtrace, 查看程序运行到当前位置之前所有的堆栈帧情况)(gdb) quit —— 退出如果不知道core文件由哪个文件产生的，可使用file命令显示$ file core
Ⅱ linux c内存溢出的core mp bug怎么跟
浅析Linux下core文件当我们的程序崩溃时，内核有可能把该程序当前内存映射到core文件里，方便程序员找到程序出现问题的地方。最常出 现的，几乎所有C程序员都出现过的错误就是“段错误”了。也是最难查出问题原因的一个错误。下面我们就针对“段错误”来分析core文件的产生、以及我们 如何利用core文件找到出现崩溃的地方。何谓core文件当一个程序崩溃时，在进程当前工作目录的core文件中复制了该进程的存储图像。core文件仅仅是一个内存映象(同时加上调试信息)，主要是用来调试的。当程序接收到以下UNIX信号会产生core文件：名字 说明 ANSI C POSIX.1 SVR4 4.3+BSD 缺省动作SIGABRT 异常终止(abort) . . . . 终止w/coreSIGBUS 硬件故障 . . . 终止w/coreSIGEMT 硬件故障 . . 终止w/coreSIGFPE 算术异常 . . . . 终止w/coreSIGILL 非法硬件指令 . . . . 终止w/coreSIGIOT 硬件故障 . . 终止w/coreSIGQUIT 终端退出符 . . . 终止w/coreSIGSEGV 无效存储访问 . . . . 终止w/coreSIGSYS 无效系统调用 . . 终止w/coreSIGTRAP 硬件故障 . . 终止w/coreSIGXCPU 超过CPU限制(setrlimit) . . 终止w/coreSIGXFSZ 超过文件长度限制(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是被执行的程序名的前1 6个字符。它对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 SVR4和4.3+BSD支持资源限制的概念。如果进程超过了其软C P U时间限制，则产生此信号。• SIGXFSZ 如果进程超过了其软文件长度限制，则SVR4和4.3+BSD产生此信号。摘自《UNIX环境高级编程》第10章 信号。使用core文件调试程序看下面的例子：/*core_mp_test.c*/#include const char *str = "test";void core_test(){ str[1] = 'T';}int main(){ core_test(); return 0;}编译：gcc –g core_mp_test.c -o core_mp_test如果需要调试程序的话，使用gcc编译时加上-g选项，这样调试core文件的时候比较容易找到错误的地方。执行：./core_mp_test段错误运行core_mp_test程序出现了“段错误”，但没有产生core文件。这是因为系统默认core文件的大小为0，所以没有创建。可以用ulimit命令查看和修改core文件的大小。ulimit -c 0ulimit -c 1000ulimit -c 1000-c 指定修改core文件的大小，1000指定了core文件大小。也可以对core文件的大小不做限制，如：ulimit -c unlimitedulimit -c unlimited如果想让修改永久生效，则需要修改配置文件，如 .bash_profile、/etc/profile或/etc/security/limits.conf。再次执行：./core_mp_test段错误 (core mped)ls core.*core.6133可以看到已经创建了一个core.6133的文件.6133是core_mp_test程序运行的进程ID。调式core文件core文件是个二进制文件，需要用相应的工具来分析程序崩溃时的内存映像。file core.6133core.6133: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'core_mp_test'在Linux下可以用GDB来调试core文件。gdb core_mp_test core.6133GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)Copyright 2003 Free Software Foundation, Inc.GDB is free software, covered by the GNU General Public License, and you arewelcome to change it and/or distribute copies of it under certain conditions.Type "show ing" to see the conditions.There is absolutely no warranty for GDB. Type "show warranty" for details.This GDB was configured as "i386-redhat-linux-gnu"…Core was generated by `./core_mp_test'.Program terminated with signal 11, Segmentation fault.Reading symbols from /lib/tls/libc.so.6…done.Loaded symbols for /lib/tls/libc.so.6Reading symbols from /lib/ld-linux.so.2…done.Loaded symbols for /lib/ld-linux.so.2#0 0x080482fd in core_test () at core_mp_test.c:77 str[1] = 'T';(gdb) where#0 0x080482fd in core_test () at core_mp_test.c:7#1 0x08048317 in main () at core_mp_test.c:12#2 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6GDB中键入where，就会看到程序崩溃时堆栈信息（当前函数之前的所有已调用函数的列表（包括当前函数），gdb只显示最近几个），我们很容易找到我们的程序在最后崩溃的时候调用了core_mp_test.c 第7行的代码，导致程序崩溃。注意：在编译程序的时候要加入选项-g。您也可以试试其他命令，如fram、list等。更详细的用法，请查阅GDB文档。core文件创建在什么位置在进程当前工作目录的下创建。通常与程序在相同的路径下。但如果程序中调用了chdir函数，则有可能改变了当前工 作目录。这时core文件创建在chdir指定的路径下。有好多程序崩溃了，我们却找不到core文件放在什么位置。和chdir函数就有关系。当然程序 崩溃了不一定都产生core文件。什么时候不产生core文件在下列条件下不产生core文件：( a )进程是设置-用户-ID，而且当前用户并非程序文件的所有者；( b )进程是设置-组-ID，而且当前用户并非该程序文件的组所有者；( c )用户没有写当前工作目录的许可权；( d )文件太大。core文件的许可权(假定该文件在此之前并不存在)通常是用户读/写，组读和其他读。利用GDB调试core文件，当遇到程序崩溃时我们不再束手无策。
Ⅲ linux上的core文件，麻烦牛人们帮忙解释下是什么原因
关于UNIX/Linux系统来下面产生的core文件，根据我自使用系统的经验，通常是由于自己在编写程序的过程中，由于自己的疏忽，使自己编写的程序产生了数组越界、或者是程序中的指针指向了一块无效的内存区域，产生的内存溢出错误。这一点在C语言编程过程中尤为明显，即：虽然定义了一个指针变量，但是未对该变量进行初始化、且判断该指针是否为空指针，而在后面的程序中又使用到了该变量，这时候肯定就会产生内存溢出错误。通常产生的提示信息就是：Segmentfault，CoreDumped！此时再一看自己当前工作的目录下面，就会自动产生出一个文件名为core的文件，通常该文件占得空间也是比较大的，至少好几兆字节。
Ⅳ 1 linux下调试core的命令，察看堆栈状态命令
比方说，你要调试的core文件是 core.xxx，原始可执行文件是 a.exe先用 gdb a.exe 进入 gdb，在gdb命令行下 执行core-file /path/to/core.xxx然后专即可调试core mp文件了，比如用 bt 等属
Ⅳ 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.19344GNU 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 arewelcome to change it and/or distribute copies of it under certain conditions.Type “show ing” 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.0Reading symbols from /lib/i686/libm.so.6…done.Loaded symbols for /lib/i686/libm.so.6Reading symbols from /usr/lib/libz.so.1…done.Loaded symbols for /usr/lib/libz.so.1Reading symbols from /usr/lib/libstdc++.so.5…done.Loaded symbols for /usr/lib/libstdc++.so.5Reading symbols from /lib/i686/libc.so.6…done.Loaded symbols for /lib/i686/libc.so.6Reading symbols from /lib/libgcc_s.so.1…done.Loaded symbols for /lib/libgcc_s.so.1Reading symbols from /lib/ld-linux.so.2…done.Loaded symbols for /lib/ld-linux.so.2Reading 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行，基于此，我们就可以有针对性的找到问题的根源，并加以解决。
Ⅵ 谁能告诉我linux下出core，core究竟是什么
就是一个程序出错时，相关的调试信息，生成的一个文件。可以对它调试，得到出错原因。用gdb就可以了。但你的程序必须带gdb信息。也就是说，在编译的时候要指定-g 参数。
