环境变量设置
可以通过 /etc/security/limits 文件对各用户的基本配置参数包括 core 大小进行限制。或者通过 ulimit 更改当前环境下的 core 大小限制。
默认情况下,应用进程生成 core dump 时都使用文件名 core。为了避免同一工作目录下的进程 core 相互覆盖,可以定义环境变量 CORE_NAMING=true,然后启动进程,这样将生成名为 core.pid.ddhhmmss 的文件。可以使用 file core 命令查看 core 是哪个进程产生的。
默认情况下,应用进程 dump 时会包含所有的共享内存,如果 dump 时想排除共享内存内容,可以在启动进程之前设置环境变量 CORE_NOSHM=true.
系统有一个参数 fullcore 用于控制是否在程序 coredump 时生成完整的 core。为避免信息丢失,建议打开 fullcore。可以使用 lsattr –El sys0 查询是否将 fullcore 打开,使用 chdev -l sys0 -a fullcore=true 将 fullcore 状态更改为打开。也可以在程序内部调用 sigaction 例程设置 fullcore,参考如下测试程序:
|
应用进程的 core 产生在其当前工作目录下,可以在应用程序内部使用 chdir 函数切换当前工作目录。使用 procwdx 命令可以查看进程的当前工作目录。系统的 core 生成在 lg_dumplv 下,并在重启时转移到 /var/adm/ras/ 目录下(如果有足够空间的话,否则继续保留在 lg_dumplv,并随时有可能被覆盖)。
可以使用 errpt -a 查看标识 C0AA5338 SYSDUMP(系统 core)、B6048838 CORE_DUMP(进程 core)的详细错误信息,获取生成 core 的进程以及 core 文件位置。使用 snap –ac 收集系统的 dump 信息。
如果可能 , 直接在发生 coredump 的机器上用 dbx 分析出结果 , 这样是最方便的分析方法 . 这种情况下注意不要直接以 root 用户登录然后用 dbx 分析 , 而必须在应用程序所属的用户下进行此操作 , 因为 core 可能需要依赖应用程序运行时对应环境下的某些库 , 这样就要借助应用程序的环境变量 .
如果需取回生产机上的 core 信息在实验室分析 , 则需要搜集一些相关信息 . 进程 core 分析一般至少需要依赖应用可执行程序,有时还需要包括一些运行时动态库信息。如果需要收集 core 相关的完整信息,可运行 snapcore <core 路径以及名称 > < 可执行文件以及名称 >,例如 snapcore ./core ./a.out,然后在 /tmp/snapcore 下取下相应的 .pax.Z 文件。
正常的收集过程应该如下 :
|
dbx 是 AIX 下基于命令行界面的源码级调试工具。本文档只提供一些基本的 dbx 分析指令,详细内容请参考“General Programming Concepts: Writing and Debugging Programs”关于 dbx 的描述。