我在这里做了一个小噩梦.我目前正在做一些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.outgdb ./a.out ./coreulimit -c 0echo "profit"总结
以上是内存溢出为你收集整理的哪个核心转储? (Linux)的全部内容,希望文章能够帮你解决哪个核心转储? (Linux)的所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)