TLDR：即使在设置ulimit并查看apport之后也找不到核心转储.厌倦了努力工作以获得单一的回溯.关于底部的问题.

我在这里做了一个小噩梦.我目前正在做一些c编码,在我的情况下总是意味着一公吨的段错误.大多数时候我能够很容易地重现这个bug,但是今天我碰到了一堵墙.

我的代码不一致地产生段错误.我需要它正在讨论的核心转储.

因此,我正在寻找一个核心转储,因为我的小宝贝a.out.那就是我开始脱掉头发的时候.

我的直觉告诉我,核心转储文件应该存储在工作目录的某个地方 – 显然情况并非如此.阅读this之后,我高兴地输入：

ulimit -c 750000

没别的了.我的程序输出告诉我,它做了核心转储 – 但我无法在cwd中找到它.所以在阅读了this之后,我了解到我应该做的事情是apport和core_pattern.

改变core_pattern对于获得一个核心转储似乎有点太多了,我真的不想搞砸它,因为我知道我以后会忘记它.而且我倾向于把这些事搞得一团糟.

Apport有这种神奇的属性,选择哪些核心转储是有价值的,哪些不是.它的日志告诉我……

ERROR: apport (pid 7306) Sun Jan  3 14:42:12 2016: executable does not belong to a package, ignoring

…我的程序不够好.

>这个核心转储文件在哪里？
>有没有办法手动一次获取核心转储,而无需设置所有内容？我很少需要那些作为文件本身,大多数时候GDB就足够了.类似于let_me_look_at_the_core_dump<程序名称>会很好.

我已经秃了一点,所以任何帮助都会受到赞赏.

解决方法:

所以,今天我学到了：

>重新打开shell后,ulimit重置.
>我在.zshrc中犯了一个大错 – zsh嵌套并在输入一些命令后重新打开.

在摆弄了一下后,我也找到了第二个问题的解决方案.制作shell脚本：

ulimit -c 750000
./a.out
gdb ./a.out ./core
ulimit -c 0
echo "profit"