GDB 回溯不显示函数名称
我编译了我的库（特别是 protbuf-2.3.0）在 SunOS 5.10 上使用 -g -O0。
make 日志中的示例行如下：
/bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -pthreads -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g -O0 -MT text_format.lo -MD -MP -MF .deps/text_format.Tpo -c -o text_format.lo `test -f 'google/protobuf/text_format.cc' || echo './'`google/protobuf/text_format.cc
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -pthreads -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g -O0 -MT text_format.lo -MD -MP -MF .deps/text_format.Tpo -c google/protobuf/text_format.cc -fPIC -DPIC -o .libs/text_format.o
然后，我使用以下步骤附加了 gdb：
- 运行我的应用程序（在本例中，我的 Web 服务器启动一个 java web 应用程序，该应用程序在启动期间通过 jni 使用库）。
- 我通过 gdb -p XXX 将 gdb 连接到该进程（其中 XXX 是我从 ps 获取的 pid）。
- 然后我在 gdb 提示符下使用
file libprotobuf.so从 gdb 加载我的库。
但我无法从 bt 中看到我的函数名称。我的 GDB backtrace 命令显示如下：
(gdb) bt
#0 0xf8f98914 in ?? ()
#1 0xf8f98830 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
我也尝试做 #1 &仅#2，#1 和#1仅#3，以及#1 和#1。 gdb libprotobuf.so -p XXX。
除此之外，我还尝试在调试模式下运行 jvm 并在 System.loadLibrary(..) 命令上添加断点，在单步执行该命令后，我再次执行 gdb 附加过程....但还是什么都没有。
但是，我可以在给定函数名称的情况下放置断点，并通过 list 列出函数的内容。但话又说回来，我可以放置断点，但它们不会在这些函数名称上停止（我知道它会转到该函数，因为每次 jvm 崩溃后它都在 jvm hs_err_pid 报告中）。
有什么想法吗？它没有向我显示我的函数名称？
I compiled my library (specifically protbuf-2.3.0) using -g -O0 on a SunOS 5.10.
A sample line in the make log is this:
/bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -pthreads -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g -O0 -MT text_format.lo -MD -MP -MF .deps/text_format.Tpo -c -o text_format.lo `test -f 'google/protobuf/text_format.cc' || echo './'`google/protobuf/text_format.cc
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -pthreads -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g -O0 -MT text_format.lo -MD -MP -MF .deps/text_format.Tpo -c google/protobuf/text_format.cc -fPIC -DPIC -o .libs/text_format.o
And then, I attached my gdb using the following steps:
- Run my application (in this case, my web server which starts up a java web app which uses a library via jni during startup).
- I attached my gdb to that process via
gdb -p XXX(where XXX is the pid I got fromps). - And then I loaded my library from the gdb using
file libprotobuf.sofrom the gdb prompt.
But I can't see my function names from bt. My GDB backtrace command shows something like this:
(gdb) bt
#0 0xf8f98914 in ?? ()
#1 0xf8f98830 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
I also tried doing #1 & #2 only, #1 & #3 only, and #1 & gdb libprotobuf.so -p XXX.
Aside from those, I also tried running my jvm on debug mode and added a breakpoint on the System.loadLibrary(..) command, and after stepping over that command, I then did the gdb attachment process again....but still nothing.
However, I am able to put breakpoints given function names and list the contents of a function via list. But then again, I can place breakpoints but they don't stop as well on those function names (I know it went to that function because it's in the jvm hs_err_pid report after every jvm crash).
Any ideas come it's not showing me my function names?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
问题很可能是 GDB 不知道如何找出给定 PID 的完整可执行路径。如果它确实知道完整路径，则无需执行步骤#3——GDB 会自动添加它。
您可以使用
(gdb) info file命令验证 GDB 是否正确推断出可执行文件名称。如果我的猜测是正确的，请通过像这样调用它来帮助 GDB：
这应该立即解决您的所有问题。
The problem is most likely in that GDB does not know how to figure out full executable path for the given PID. If it did know full path, you wouldn't need to do step #3 -- GDB would have added it automatically.
You can verify whether GDB deduced executable name correctly with
(gdb) info filecommand.If my guess is correct, help GDB by invoking it like this:
That should immediately solve all of your problems.
此外，请确保使用您的库的可执行文件不会在某处被删除。
Additionally, be sure that the executable that uses your library isn't getting stripped somewhere.
我认为这是链接问题。您可以检查一下链接时执行的命令吗？希望这会有所帮助。
I think that is linking problem. Can you check your command which is executed at the time of linking. Hope this will help.