CODEWITHSUNDEEP
gdbstack
Anycorn
Anycorn

Reputation: 51435

gdb stack strangeness

I get this weird backtrace (sometimes):

(gdb) bt
#0  0x00002b36465a5d4c in AY16_Loop_M16 () from /opt/intel/mkl/10.0.3.020/lib/em64t/libmkl_mc.so
#1  0x00000000000021da in ?? ()
#2  0x00000000000021da in ?? ()
#3  0xbf3e9dec2f04aeff in ?? ()
#4  0xbf480541bd29306a in ?? ()
#5  0xbf3e6017955273e8 in ?? ()
#6  0xbf442b937c2c1f37 in ?? ()
#7  0x3f5580165832d744 in ?? ()
...

Any ideas why i cant see the symbols? Compiled with debugging syms of course. The same session gives symbols at other points.

Upvotes: 2

Views: 1349

Answers (2)

Employed Russian
Employed Russian

Reputation: 213385

The AY16_Loop_M16() in libmkl_mc.so most likely was written in assembly, and does not have correct unwind descriptors, which are required for GDB to properly unwind stack on x86_64 (in the absence of frame pointers).

Your best bet is to contact Intel, and ask them to add proper unwind descriptors.

You may get better results if you set a breakpoint on the start of AY16_Loop_M16 -- if it is called from C (or any other non-assembly language), chances are you'll get a reasonable stack trace on entry.

Upvotes: 3

TheCoolah
TheCoolah

Reputation: 529

While your code may be compiled with debugging symbols, the same may not be true of the shared libraries. You may need to install debug versions of those libraries to get those symbols.

You can still use GDB to debug your own code. Just ignore the unknown locations and look for your own function calls in the backtrace. Odds are good that the problem is not in the shared libraries anyway.

Upvotes: 1

Related Questions