Unix 上的分段错误 - 可能的堆栈损坏
我正在查看 Unix 中运行的进程的核心。 通常我可以解决问题并深入回溯以尝试识别内存问题。 在这种情况下，我不确定如何继续。
首先，回溯只给出了 3 帧，我期望更多。 对于这些框架，提供的所有功能参数似乎完全无效。 没有我所期望的。
某些指针参数具有以下关联 - 无法访问地址处的内存
这是否表明某种完全堆栈损坏。 我使用 libumem 运行该过程，所有缓冲区都报告为干净的。
umem_status 也没有报告任何内容。
所以基本上我很困惑。 可能的原因是什么？ 由于 libumem 似乎没有报告任何错误，我应该在代码中查找什么。
关于如何进一步调试有什么建议吗？ 我应该考虑 mdb 中的任何额外功能吗？
谢谢。
i'm looking at a core from a process running in Unix.
Usually I can work my around and root into the backtrace to try identify a memory issue.
In this case, I'm not sure how to proceed.
Firstly the backtrace only gives 3 frames where I would expect alot more.
For those frames, all the function parameters presented appears to completely invalid.
There are not what I would expect.
Some pointer parameters have the following associated with them - Cannot access memory at address
Would this suggest some kind of complete stack corruption.
I ran the process with libumem and all the buffers were reported as being clean.
umem_status reported nothing either.
so basically I'm stumped.
What is the likely causes?
What should I look for in code since libumem appears to have reported no errors.
Any suggestions on how I can debug furhter? any extra features in mdb I should consider?
thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
堆栈损坏听起来确实有可能。 一些可以尝试的事情：
Stack corruption does sound like a possibility. Some things to try:
您可以查看是否使用 Valgrind 或 ElectricFence 可能会提前损坏。
You can look into if using Valgrind or ElectricFence could break a little earlier for you.
libumem 不应该报告与电围栏相同的超限情况吗？
在测试环境中无法轻松重现，但在 unix/solaris 下的商业环境中会出现核心，但 libumem 显示没有什么不好，
shouldnt libumem report the same overrun as electric fence?
can't reproduce easy in test environment but in commercial env under unix/solaris the core occurs but libumem shows nothing bad,
你的代码？ 当这种情况发生在我身上时，我总是发现同样的事情：空指针。 崩溃时看起来很可怕，但原因最终很简单。
Your code? When this happens to me, I always find the same thing: A null pointer. Looks horrible when it crashes, but the cause is ultimately simple.
我确实遇到了类似的问题。 GDB 的回溯没有帮助。 Valgrind 来救我了。
通过 Valgrind 运行您的应用程序。 识别所有错误，例如无效写入。 分析这段代码，看看是否可以修复它们。
就我而言，我尝试进行无效写入（有时可能会写入 NULL），该写入不是在该实例上而是在其他地方显示其效果。
I did run into similar issue. The backtrace from GDB was not helpful. Valgrind came to my rescue.
Run your application through Valgrind. Identify all the errors like invalid writes. Analyze the piece of code and see if they can be fixed.
In my case I was attempting a invalid write(which at times might write NULL) which showed its effect not at that instance but else where.