根据前面所述,可执行文件的type=LOAD的segment才会被装载,但是并不会把所有的data和code都加载到内存,因为这样浪费空间也没有必要;装载的时候是按照page(默认为4KB,也就是0x1000)对齐的方式进行加载,加载之后,程序运行时所访问的地址仍然是虚拟地址,这个虚拟地址就是前文所述的“内存虚拟地址”,而 加载之后的数据毕竟是存在于“物理内存”中的,所以这个“内存虚拟地址”和“物理内存地址”之间需要有一个转换,而这个转换工作是“MMU”物理部件来完成的;MMU物理部件管理“内存虚拟地址”到“物理内存地址”的映射;
程序运行到某个代码段或者访问数据的时候,如果在内存中找不到数据,那么就会产生一种叫做page fault的异常,然后进入异常处理程序,而这个异常处理的过程所作的事情是: 把数据从物理磁盘或者swap空间 调入到内存,并做好“虚拟内存地址” 到“物理内存地址”的mapping. 处理完异常之后,程序会回到原来的断点继续运行;
如果程序在运行的过程中发生了内存访问错误,通常会触发core dump, 如果系统开启了core dump, 那么会导出当时的系统内存映像到一个core dump的文件里面,然后可以用gdb 工具对这个core dump 文件进行调式,从而尽可能获得当时的内存状况,分析发生crash的原因,core dump 中使用的地址依然是”内存虚拟地址“, 所以 在程序运行的过程中,我们完全可以不考虑”内存物理地址“,因为”内存虚拟地址“ 到”内存物理地址“的mapping 对程序员来说是透明的,即便是进行debug,也无需关心”内存物理地址“。
%p - insert pid into filename
%u - insert current uid into filename
%g - insert current gid into filename
%s - insert signal that caused the coredump into the filename
%t - insert UNIX time that the coredump occurred into filename
%h - insert hostname where the coredump happened into filename
%e - insert coredumping executable name into filename
默认的路径为: /var/logs, 而因为默认的/var/logs 并不是系统自带的路径,所以必须手动创建该目录,否则 core dump 触发的时候也不会生成相应的文件.
[root@www kernel]# bash #产生一个新的session
[root@www kernel]# ulimit -c unlimited
[root@www kernel]# echo "/root/core_%p_%s_%e.%h.%t" >./core_pattern
[root@www kernel]# kill -s SIGSEGV $$ #发送信号,让其触发core dump.
Segmentation fault (core dumped)
[root@www kernel]# ls -l /root | grep core #生成的core dump 文件
-r--------+ 1 root root 1417216 Mar 8 17:06 core_3427_11_bash.www.my.com.1583658365
[root@www kernel]#
上面例子,表示成功生成了core dump 文件,core dump的配置成功完成;