Linux 中的核心转储文件是什么？它提供什么信息？
Linux 中的核心转储文件是什么？它提供了哪些信息？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
Linux 中的核心转储文件是什么？它提供了哪些信息？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（2）
它基本上是崩溃时正在使用的进程地址空间（来自包含所有虚拟内存区域的
mm_struct结构），以及任何其他支持信息*a。例如，假设您尝试取消引用 NULL 指针并收到 SEGV 信号，导致您退出。作为该过程的一部分，操作系统尝试将您的信息写入文件以供以后事后分析。
您可以将核心文件与可执行文件（例如符号和其他调试信息）一起加载到调试器中，然后四处查看以尝试找出导致问题的原因。
*a：在内核版本 2.6.38 中，
fs/exec.c/do_coredump()是负责核心转储的函数，您可以看到它传递了信号号、退出代码和寄存器。它依次将信号号和寄存器传递给特定于二进制格式（ELF、a.out 等）的转储器。ELF转储器是
fs/binfmt_elf.c/elf_core_dump ()，您可以看到它在fs/binfmt_elf.c/fill_note_info()，然后返回输出进程空间。It's basically the process address space in use (from the
mm_structstructure which contains all the virtual memory areas), and any other supporting information*a, at the time it crashed.For example, let's say you try to dereference a NULL pointer and receive a SEGV signal, causing you to exit. As part of that process, the operating system tries to write your information to a file for later post-mortem analysis.
You can load the core file into a debugger along with the executable file (for symbols and other debugging information, for example) and poke around to try and discover what caused the problem.
*a: in kernel version 2.6.38,
fs/exec.c/do_coredump()is the one responsible for core dumps and you can see that it's passed the signal number, exit code and registers. It in turn passes the signal number and registers to a binary-format-specific (ELF, a.out, etc) dumper.The ELF dumper is
fs/binfmt_elf.c/elf_core_dump()and you can see that it outputs non-memory-based information, like thread details, infs/binfmt_elf.c/fill_note_info(), then returns to output the process space.如果程序异常终止，则应记录异常终止时程序的状态以供进一步分析。并且此状态记录在核心转储文件中。
在多用户和多任务环境中，访问不属于您的资源是不可接受的。如果进程 A 尝试访问属于进程 B 的系统资源，则属于违规。此时，操作系统杀死该进程并将进程状态存储到文件中。这个文件称为核心转储文件。造成核心转储的原因有很多。我刚刚解释了核心转储的可能性之一。通常是因为 SIGSEGV（分段错误）和 SIGBUS（总线错误）。
核心转储文件包含异常终止发生位置、进程堆栈、符号表等详细信息。
有许多工具可用于调试核心转储。
数据库
数据库
对象转储
mdb
编译器选项的存在使调试过程更加容易。而编译时给出这些标志（通常是 -g ）将导致在目标文件的符号表中留下额外的信息，这有助于调试器（gdb/dbx）轻松访问符号（符号引用）。
If a program terminates abnormally, the status of the program at the point of abnormal termination should be recorded for further analysis. and this status is recorded in core dump file.
In a multiuser and multitasking environment, accessing resources which doesn't belong to you is not acceptable. If a process-A tries to access system resources which belongs to process-B, Its a violation. At this point of time, the operating system kills the process and stores the process status into a file. And this file is called core dump file. There are many reasons for core dump. I just explained one of the possibilities for core dump. Usually it will be because of SIGSEGV (segmentation fault) and SIGBUS(Bus error).
The core dump file contains details of where the abnormal termination happened, process stack, symbol table etc.
There are many tools available to debug the coredumps.
gdb
dbx
objdump
mdb
Compiler options are present to make the debugging process easier. while compilation giving these flags (-g usually) will result in leaving extra information in symbol table of object files, which helps debuggers (gdb/dbx) to easily access the symbols(symbolic references).