分割错误后清空核心转储文件

我正在运行一个程序,并被Segmentation故障中断。 问题是核心转储文件被创build,但大小为零。

你有没有听说过这样的情况,以及如何解决?

我在磁盘上有足够的空间。 我已经执行了ulimit -c unlimited来限制核心文件的大小 – 无论是运行还是放在提交的batch file的顶部 – 但仍然有0字节的核心转储文件。 包含这些文件的文件夹的权限为uog + rw,创build的核心文件的权限仅为u + rw。

这个程序是用C ++编写的,用Grid Engine的qsub命令在一个linux集群上提交的,我不知道这个信息是否与这个问题有关。

Solutions Collecting From Web of "分割错误后清空核心转储文件"

设置ulimit -c unlimited打开生成的转储。 默认情况下,核心转储是在nfs上的当前目录中生成的。 设置/proc/sys/kernel/core_pattern/tmp/core帮我解决了空转储的问题。

Ranjith Ruban的评论帮助我开发了这个解决方法。

你用来转储内核的文件系统是什么?

这听起来像你正在使用批处理调度程序来启动您的可执行文件。 也许Torque / PBS用来产生你的工作的shell会继承一个不同的ulimit值? 也许调度程序的默认配置是不保存核心转储?

你能直接从命令行运行你的程序吗?

或者,如果您在调用可执行文件之前将ulimit -c unlimited和/或ulimit -s unlimited到了PBS批处理脚本的顶部,那么您可能会覆盖PBS的默认ulimit行为。 或者添加'ulimit -c'可以报告无论如何限制。

您可以通过使用qsub选项(例如-l h_vmem=6G来设置资源限制(如物理内存),以-l h_vmem=6G 6 GB的物理内存。

对于文件块,您也可以将h_fsize设置为适当的值。

请参阅qconf手册页的RESOURCE LIMITS部分:

http://gridscheduler.sourceforge.net/htmlman/htmlman5/queue_conf.html

 s_cpu The per-process CPU time limit in seconds. s_core The per-process maximum core file size in bytes. s_data The per-process maximum memory limit in bytes. s_vmem The same as s_data (if both are set the minimum is used). h_cpu The per-job CPU time limit in seconds. h_data The per-job maximum memory limit in bytes. h_vmem The same as h_data (if both are set the minimum is used). h_fsize The total number of disk blocks that this job can create. 

另外,如果集群使用本地TMPDIR到每个节点,并且正在填满,则可以将TMPDIR设置为具有更多容量的备用位置,例如NFS共享:

 export TEMPDIR=<some NFS mounted directory> 

然后用-V选项启动qsub以将当前环境导出到作业。

上面的一个或上述的组合可以帮助你解决你的问题。

如果在安装的驱动器中运行核心文件,则不能将核心文件写入已装入的驱动器,而必须将其写入本地驱动器。

您可以将文件复制到本地驱动器。