从进程内部使用 gdb 获取堆栈跟踪
在我的代码中，我有一些运行时断言宏（我们称之为runtime_assert）。 这应该在多线程应用程序中。
当条件传递评估为 false 时，runtime_assert 通过转储堆栈跟踪来终止程序，然后调用 _exit()。
您可能知道，转储堆栈跟踪并不是一项简单的任务（How to get a stack使用 gcc 跟踪 C++ 以及行号信息？）。
这个想法是通过调用 system() 来使用进程的 pid 来调用 gdb。
- 总的来说这是个好主意吗？ 或者最好使用仅流程工具来获取回溯？ （例如海湾合作委员会
backtrace()/backtrace_symbols()) - 当调用 ptrace() 时，它会以某种方式影响其他线程吗？
- 如果系统资源不足（例如内存/磁盘空间），gdb fork 可能会失败吗？
- 如何仅打印当前线程的堆栈跟踪？ （我可以从 gcc backtrace() 获取当前方法的地址）
In my code I have some runtime assert macro (let's call it runtime_assert).
This should be in multi threaded application.
When condition passed evaluated to false, runtime_assert terminates program by dumping stack trace , followed by calling _exit().
As you probably know, dumping stack trace isn't a trivial task (How to get a stack trace for C++ using gcc with line number information?).
The idea is to invoke gdb with pid of the process by calling system().
- Is it good idea in general?
Or it's better to use process only tools to get backtrace? (e.g. gcc
backtrace()/backtrace_symbols()) - When ptrace() is invoked, will it somehow effect other threads?
- If system is out of resources (e.g. memory/disk space) may gdb fork fail?
- How to print stack trace of current thread only?
(I can get address of current method from gcc backtrace())
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我记得不久前在 SO 上也有过类似的讨论。在搜索论坛后，我发现是您提出的，并且与您在这个问题中指出的主题相同。
你看到诺巴尔的回答了吗？看来这正是您正在寻找的。诀窍是使用execlp来调用gdb而不是system：
如何使用 gcc 和行号信息获取 C++ 的堆栈跟踪？
I remember a similar discussion about this some time ago on SO. After searching the forum I found that it was you who asked, and it's the same thread you point out in this question.
Have you seen nobar's answer? It seems it's exactly what you are looking for. The trick is to use execlp to invoke gdb instead of system:
How to get a stack trace for C++ using gcc with line number information?
system()完成并且 GDB 附加其他线程时，问题点就已经远远超出了。实际上，我什至认为在这种情况下，不必费心去处理堆栈跟踪（当您将应用程序提供给一些“不太复杂”的用户时，这可能会有所帮助，并且您从他们那里获得的任何信息都是有用）。在这里，我只需abort()并有一个很好的核心文件可供细读。gettid()和 GDB 初始化文件以及用户定义的命令技巧来完成，但同样，我认为我不会打扰。system()is done and GDB attaches other threads are way beyond the trouble point. I actually don't even think bothering with stack trace is worth it in this case (it might help when you give your app to some "less-sophisticated" users and any info you get out of them is useful). Here I'd justabort()and have a nice core file to peruse.gettid()and GDB init-file and user-defined command trickery, but again, don't think I would bother.