內存泄漏通常是指程序中動態分配的內存沒有被適時釋放，導致這部分內存在程序的生命周期內一直無法被再次利用。內存泄漏不會直接導致程序崩潰，所以通常不會生成core dump文件。然而，如果程序因為其他原因崩潰，那么core dump文件可能會包含一些關于內存泄漏的信息。

要分析內存泄漏，通常需要使用特定的內存分析工具，如Valgrind、AddressSanitizer (ASan) 等，這些工具可以在程序運行時監控內存分配和釋放，從而幫助發現內存泄漏。不過，如果程序已崩潰并產生了core dump文件，可以使用GDB等調試器查看程序的內存使用情況，但這種方法通常不如專用工具直接。

假設我們有以下C程序，它會造成內存泄漏：

#include <stdlib.h>void create_memory_leak() {int *leak = malloc(sizeof(int) * 100); // 動態分配內存但未釋放 
*leak = 123; // 使用分配的內存 
// 這里應該有 free(leak); 但是遺漏了
} 
int main() {create_memory_leak(); // 調用函數造成內存泄漏 
// 這里可能有其他操作導致程序崩潰，從而生成core dump
 return 0; 
}

這段代碼中，函數create_memory_leak分配了內存但沒有釋放。如果程序由于其他原因崩潰，我們可以使用GDB來查看程序的內存分配情況。但是，請注意，內存泄漏本身不會在core dump文件中直接體現。

使用Valgrind運行程序：

valgrind --leak-check=full ./memory_leak_example

Valgrind將會報告內存泄漏的信息，類似于：

==12345== LEAK SUMMARY: ==12345== definitely lost: 400 bytes in 1 blocks ==12345== indirectly lost: 0 bytes in 0 blocks ==12345== possibly lost: 0 bytes in 0 blocks ==12345== still reachable: 0 bytes in 0 blocks ==12345== suppressed: 0 bytes in 0 blocks

在GDB中查看core dump文件將不會提供直接關于內存泄漏的信息，因為GDB主要用于分析程序崩潰的原因，而不是內存泄漏的分析。要診斷內存泄漏，最好在程序運行時使用上述內存分析工具。如果內存泄漏導致程序運行緩慢或耗盡內存資源，可能會有一些間接的跡象，如不斷增長的內存占用，但這通常需要結合系統監控工具來觀察。