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 文件