views:

596

answers:

3

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:

  1. Run my application (in this case, my web server which starts up a java web app which uses a library via jni during startup).
  2. I attached my gdb to that process via gdb -p XXX (where XXX is the pid I got from ps).
  3. And then I loaded my library from the gdb using file libprotobuf.so from 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?

Thanks, Franz

A: 

I think that is linking problem. Can you check your command which is executed at the time of linking. Hope this will help.

Mayank Jain
Your answer is most unhelpful: check command for what? And why do you think this has anything to do with linking?
Employed Russian
A: 

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 file command.

If my guess is correct, help GDB by invoking it like this:

  gdb /path/to/java <PID>

That should immediately solve all of your problems.

Employed Russian
A: 

Additionally, be sure that the executable that uses your library isn't getting stripped somewhere.

Wade Williams