1. linux有多个core文件，怎么区分它们属于哪个进程
只在ubuntu上试过， 以例子说明
强制当前shell sigsegv core mp， 当前shell会退出
$kill -SIGSEGV $$
core file 已经产生
$/var/tmp/cores>ls
core
用gdb列出program name
$gdb
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show ing"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) core-file ./core
[New LWP 1808]
Core was generated by `/usr/local/bin/ksh'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f654584d707 in ?? ()
(gdb) quit
用知道的program名字来load core， 并列出stack
$gdb /usr/local/bin/ksh core
GNU gdb (GDB) 7.5-ubuntu
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show ing"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/ksh...(no debugging symbols found)...done.
[New LWP 1808]
warning: Can't read pathname for load map: Input/output error.
Core was generated by `/usr/local/bin/ksh'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f654584d707 in kill () at ../sysdeps/unix/syscall-template.S:82
82 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0 0x00007f654584d707 in kill () at ../sysdeps/unix/syscall-template.S:82
#1 0x000000000043244c in job_kill ()
#2 0x00000000004322ed in job_walk ()
#3 0x0000000000474ad9 in b_kill ()
#4 0x000000000045d871 in sh_exec ()
#5 0x0000000000412b16 in exfile ()
#6 0x00000000004135ea in sh_main ()
#7 0x0000000000411f7a in main ()
2. linux core文件大小由什么决定
你程序占用的内存空间大小，因为他是DUMP下整块内存
3. 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
4. linux上的core文件，麻烦牛人们帮忙解释下是什么原因
关于UNIX/Linux系统来下面产生的core文件，根据我自使用系统的经验，通常是由于自己在编写程序的过程中，由于自己的疏忽，使自己编写的程序产生了数组越界、或者是程序中的指针指向了一块无效的内存区域，产生的内存溢出错误。这一点在C语言编程过程中尤为明显，即：虽然定义了一个指针变量，但是未对该变量进行初始化、且判断该指针是否为空指针，而在后面的程序中又使用到了该变量，这时候肯定就会产生内存溢出错误。通常产生的提示信息就是：Segmentfault，CoreDumped！此时再一看自己当前工作的目录下面，就会自动产生出一个文件名为core的文件，通常该文件占得空间也是比较大的，至少好几兆字节。
5. linux ls 显示core.xxxx
core文件是程序崩溃时产生的，你可以用gdb来调试一下其中的内容。
你也可以禁止生成core，不过出现了异常情况最好还是查一下原因。
6. linux core 文件 怎么分析
Core，又称之为Core Dump文件，是/Linux操作系统的一种机制，对于线上服务而言，Core令人闻之色变，因为出Core的过程意味着服务暂时不能正常响应，需要恢复，并且随着吐Core进程的内存空间越大，此过程可能持续很长一段时间（例如当进程占用60G+以上内存时，完整Core文件需要15分钟才能完全写到磁盘上），这期间产生的流量损失，不可估量。
凡事皆有两面性，OS在出Core的同时，虽然会终止掉当前进程，但是也会保留下第一手的现场数据，OS仿佛是一架被按下快门的相机，而照片就是产出的Core文件。里面含有当进程被终止时内存、CPU寄存器等信息，可以供后续开发人员进行调试。
关于Core产生的原因很多，比如过去一些Unix的版本不支持现代Linux上这种GDB直接附着到进程上进行调试的机制，需要先向进程发送终止信号，然后用工具阅读core文件。在Linux上，我们就可以使用kill向一个指定的进程发送信号或者使用gcore命令来使其主动出Core并退出。如果从浅层次的原因上来讲，出Core意味着当前进程存在BUG，需要程序员修复。从深层次的原因上讲，是当前进程触犯了某些OS层级的保护机制，逼迫OS向当前进程发送诸如SIGSEGV(即signal 11)之类的信号, 例如访问空指针或数组越界出Core，实际上是触犯了OS的内存管理，访问了非当前进程的内存空间，OS需要通过出Core来进行警示，这就好像一个人身体内存在病毒，免疫系统就会通过发热来警示，并导致人体发烧是一个道理（有意思的是，并不是每次数组越界都会出Core，这和OS的内存管理中虚拟页面分配大小和边界有关，即使不出Core，也很有可能读到脏数据，引起后续程序行为紊乱，这是一种很难追查的BUG）。
说了这些，似乎感觉Core很强势，让人感觉缺乏控制力，其实不然。控制Core产生的行为和方式，有两个途径：
1.修改/proc/sys/kernel/core_pattern文件，此文件用于控制Core文件产生的文件名，默认情况下，此文件内容只有一行内容：“core”，此文件支持定制，一般使用%配合不同的字符，这里罗列几种：
%p 出Core进程的PID
%u 出Core进程的UID
%s 造成Core的signal号
%t 出Core的时间，从1970-01-0100:00:00开始的秒数
%e 出Core进程对应的可执行文件名
2.Ulimit –C命令，此命令可以显示当前OS对于Core文件大小的限制，如果为0，则表示不允许产生Core文件。如果想进行修改，可以使用：
Ulimit –cn
其中n为数字，表示允许Core文件体积的最大值，单位为Kb，如果想设为无限大，可以执行：
Ulimit -cunlimited
产生了Core文件之后，就是如何查看Core文件，并确定问题所在，进行修复。为此，我们不妨先来看看Core文件的格式，多了解一些Core文件。
7. 根目录下生成很多core.文件是什么原因
在 UNIX/Linux 系统中，core 文件往往是由于用户编写的程序有问题，但是又不是在编译内、连接程序时容就可以轻易发现的错误，但是一到运行程序时才会产生：core mped 信息。一般来说，core 文件占用的空间比较大，也没有什么太多的用处，因此可以删除掉它。
8. 如何查询和修改Linux操作系统生成core mp文件的默认路径
经过分析发现系统默认的core文件生成路径是/var/logs，但/var/logs目录并非系统自带的，系统初始安装默认自带的是/var/log，最终导致该系统出现core mp后并没能生成core文件，因此如何查询和修改系统默认的core mp文件生产路径呢？
方法如下：一. 查询core mp文件路径：
方法1： # cat /proc/sys/kerne怠珐糙貉孬股茬瘫长凯l/core_pattern。
方法2： # /sbin/sysctl kernel.core_pattern二. 修改core mp文件路径：
方法1：临时修改/proc/sys/kernel/core_pattern文件，但/proc目录本身是动态加载的，每次系统重启都会重新加载，因此这种方法只能作为临时修改。 /proc/sys/kernel/core_pattern 例：echo ‘/var/log/%e.core.%p’ > /proc/sys/kernel/core_pattern
方法2：永久修改：使戚睁辩用sysctl -w name=value命令。 例：高缺/sbin/sysctl -w kernel.core_pattern=/var/log/%e.core.%p为了更详尽的记录core mp当时的系统状态，可通过以下参数来丰富core文件的命早敬名： %% 单个%字符。
9. linux的dev下的core可以删除吗
可以，Core文件其实就是内存的映像，当程序崩溃时，存储内存的相应信息，主用用于对程序进行调试。当程序崩溃时便会产生core文件，其实准确的应该说是core mp 文件