許多沒有做過unix系統級軟體開發的人士，可能只聽說過dump，而並不知道系統dump和core dump的區別，甚至混為一談。
系統dump（system dump）
所有開放式作業系統，都存在系統dump問題。
產生原因：
由於系統關鍵/核心程序，產生嚴重的無法恢復的錯誤，為了避免系統相關資源受到更大損害，作業系統都會強行停止執行，並將當前記憶體中的各種結構、核心程序出錯位置及其**狀態，儲存下來，以便以後分析。最常見的原因是指令走飛，或者緩衝區溢位，或者記憶體訪問越界。走飛就是說**流有問題，導致執行到某一步指令混亂，跳轉到一些不屬於它的指令位置去執行一些莫名其妙的東西（沒人知道那些地方本來是**還是資料，而且是不是正確的**開始位置），或者呼叫到不屬於此程序的記憶體空間。寫過c程式及匯程式設計序的人士，對這些現象應當是很清楚的。
系統dump生成過程的特點：
在生成dump過程中，為了避免過多的操作結構，導致問題所在位置正好也在生成dump過程所涉及的資源中，造成dump不能正常生成，作業系統都用盡量簡單的**來完成，所以避開了一切複雜的管理結構，如檔案系統、lvm等等，所以這就是為什麼幾乎所有開放系統，都要求dump裝置空間是物理連續的——不用定位乙個個資料塊，從dump裝置開頭一直寫直到完成，這個過程可以只用bios級別的操作就可以。這也是為什麼在企業級unix普遍使用lvm的現狀下，dump裝置只可能是裸裝置而不可能是檔案系統檔案，而且[b]只[/b]用作dump的裝置，做 lvm映象是無用的——系統此時根本沒有lvm操作，它不會管什麼映象不映象，就用第乙份連續寫下去。
所以unix系統也不例外，它會將dump寫到乙個裸設或磁帶裝置。在重啟的時候，如果設定的dump轉存目錄（檔案系統中的目錄）有足夠空間，它將會轉存成乙個檔案系統檔案，預設情況下，[b]對於aix來說是/var/adm/ras/下的vmcore*這樣的檔案，對於hpux來說是 /var/adm/crash下的目錄及檔案。[/b]
當然，也可以選擇將其轉存到磁帶裝置。
會造成系統dump的原因主要是：
系統補丁級別不一致或缺少、系統核心擴充套件有bug（例如oracle就會安裝系統核心擴充套件）、驅動程式有 bug（因為裝置驅動程式一般是工作在核心級別的），等等。所以一旦經常發生類似的系統dump，可以考慮將系統補丁包打到最新並一致化、公升級微碼、公升級裝置驅動程式（包括fc多路冗餘軟體）、公升級安裝了核心擴充套件的軟體的補丁包等等。
程序core dump
程序core dump產生的技術原因，基本等同於系統dump，就是說從程式原理上來說是基本一致的。
但程序是執行在低一級的優先順序上（此優先順序不同於系統中對程序定義的優先順序，而是指cpu**指令的優先順序），被作業系統所控制，所以作業系統可以在乙個程序出問題時，不影響其他程序的情況下，中止此程序的執行，並將相關環境儲存下來，這就是core dump檔案，可供分析。
如果程序是用高階語言編寫並編譯的，且使用者有源程式，那麼可以通過在編譯時帶上診斷用符號表（所有高階語言編譯程式都有這種功能），通過系統提供的分析工具，加上core檔案，能夠分析到哪乙個源程式語句造成的問題，進而比較容易地修正問題，當然，要做到這樣，除非一開始就帶上了符號表進行編譯，否則只能重新編譯程式，並重新執行程式，重現錯誤，才能顯示出源程式出錯位置。
如果使用者沒有源程式，那麼只能分析到彙編指令的級別，難於查詢問題所在並作出修正，所以這種情況下就不必多費心了，找到出問題的地方也沒有辦法。
程序core dump的時候，作業系統會將程序異常終止掉並釋放其占用的資源，不可能對系統本身的執行造成危害。這是與系統dump根本區別的一點，系統dump產生時，一定伴隨著系統崩潰和停機，程序core dump時，只會造成相應的程序被終止，系統本身不可能崩潰。當然如果此程序與其他程序有關聯，其他程序也會受到影響，至於後果是什麼，就看相關程序對這種異常情況（與自己相關的程序突然終止）的處理機制是什麼了，沒有一概的定論。
如何生成coredump檔案?
登陸linux伺服器，任意位置鍵入
echo 「ulimit -c 1024」 >> /etc/profile
退出linux重新登陸linux
鍵入 ulimit -c
如果顯示 1024 那麼說明coredump已經被開啟。
//—————————————————————
1. core檔案的簡單介紹
//—————————————————————
在乙個程式崩潰時，它一般會在指定目錄下生成乙個core檔案。core檔案僅僅是乙個記憶體映象(同時加上除錯資訊)，主要是用來除錯的。
//—————————————————————
2. 開啟或關閉core檔案的生成
//—————————————————————
用以下命令來阻止系統生成core檔案:
ulimit -c 0
下面的命令可以檢查生成core檔案的選項是否開啟:
ulimit -a
該命令將顯示所有的使用者定製，其中選項-a代表「all」。
也可以修改系統檔案來調整core選項
在/etc/profile通常會有這樣一句話來禁止產生core檔案，通常這種設定是合理的:
# no core files by default
ulimit -s -c 0 > /dev/null 2>&1
但是在開發過程中有時為了除錯問題，還是需要在特定的使用者環境下開啟core檔案產生的設定
在使用者的~/.bash_profile裡加上ulimit -c unlimited來讓特定的使用者可以產生core檔案
如果ulimit -c 0 則也是禁止產生core檔案，而ulimit -c 1024則限制產生的core檔案的大小不能超過1024kb
//—————————————————————
3. 設定core dump的核心轉儲檔案目錄和命名規則
//—————————————————————
//—————————————————————
4. 使用core檔案
//—————————————————————
在core檔案所在目錄下鍵入:
gdb -c core
它會啟動gnu的偵錯程式，來除錯core檔案，並且會顯示生成此core檔案的程式名，中止此程式的訊號等等
如果你已經知道是由什麼程式生成此core檔案的，比如myserver崩潰了生成core.12345，那麼用此指令除錯:
gdb -c core myserver
以下怎麼辦就該去學習gdb的使用了
//—————————————————————
5. 乙個小方法來測試產生core檔案
//—————————————————————
直接輸入指令:
kill -s sigsegv $$
core檔案如何檢視和除錯
除錯linux程式的時候，出現segmentation fault是最鬱悶的事情了，程式 量很大的時候，可能花很多時間都找不到出錯原因。這裡介紹一種對你除錯segmentation fault很有幫助的方法，可能能迅速幫助你找到出錯的 行。這種方法需要用到linux提供的core dump機制 當程...
逆商之CORE和LEAD
c control 掌控感 要想擁有掌控感，首先就要堅信 任何事情都能做到 即使身處最糟糕的境地，你也總是有一點點可掌控的部分。你始終能掌控自己應如何應對，希望和行動正是由此產生的。o ownership 擔當力 擔當力維度的分數越高，你就越會對結果擔責。它有助於我們從建設性和實用性的角度出發，來重...
core檔案的設定和檢視
使用ulimit c 命令可檢視core檔案的生成開關，若結果為0，則便是關閉了此功能，不會生成core檔案。ulimit c unlimited 設定core的檔案大小sysctl w kernel.core pattern data core.e.p.t 設定core檔案的儲存格式和路徑以下是引...