核废料堆到底在哪里

Question

TLDR ：即使设置了ulimit并查看了apport，也找不到核心转储。厌倦了为了得到一个回溯而如此努力地工作。底部的问题

我在这里做噩梦。我目前正在做一些c编码，在我的情况下，这总是意味着一个度量吨的segfault。大多数时候，我可以在几乎没有问题的情况下复制这个bug，但今天我遇到了麻烦。

我的代码产生的segfault不一致。我需要它所说的核心转储。

所以我要去寻找一个核心垃圾堆，寻找我珍贵的a.out。就在那时，我开始把头发扯下来。

我的直觉告诉我，核心转储文件应该存储在工作目录中的某个地方——显然不是这样。看完后，我高兴地键入：

ulimit -c 750000

而且。。。没有什么我的程序输出告诉我它进行了核心转储，但我在cwd中找不到它。所以在读了这篇文章之后，我学会了我应该对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

我的程序不够好。

---

1. 这个核心转储文件在哪里
2. 有没有一种方法可以手动获得一次核心转储，而不必设置所有内容？我很少需要这些文件本身，大多数时候光是GDB就足够了。像let_me_look_at_the_core_dump <program name>这样的东西会很棒

我已经有点秃顶了，所以任何帮助都将不胜感激。

Answer 1

所以，今天我学到了：

• ulimit在重新打开外壳后重置
• 我在我的.zshrc-zsh嵌套中犯了一个大错误，并在键入一些命令后重新打开了它自己

在这个问题上花了点功夫之后，我也找到了第二个问题的解决方案。制作shell脚本：

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