CODEWITHSUNDEEP
clinuxgdb
Dylan Klomparens
Dylan Klomparens

Reputation: 2932

Interpreting a gdb backtrace

I used gdb to attach to a process. I am trying to figure out why it's stuck in an infinite loop, and what it's doing. I issued the command backtrace in gdb and got this result:

#0  0x000000000041cf30 in _talloc_free@plt ()
#1  0x0000000000452320 in winbindd_reinit_after_fork ()
#2  0x00000000004524e6 in fork_domain_child ()
#3  0x0000000000453585 in wb_child_request_trigger ()
#4  0x000000381d2048e2 in tevent_common_loop_immediate () from /lib64/libtevent.so.0
#5  0x00007fbed6b98e17 in run_events_poll () from /lib64/libsmbconf.so.0
#6  0x00007fbed6b9922e in s3_event_loop_once () from /lib64/libsmbconf.so.0
#7  0x000000381d204060 in _tevent_loop_once () from /lib64/libtevent.so.0
#8  0x000000000042049a in main ()

My question is: what does the @ symbol mean in the first line? I know that _talloc_free is a function, but what does @plt mean? Also, just to be sure: are the numbers in the second column the address of the function in memory?

Upvotes: 2

Views: 1340

Answers (2)

mpontillo
mpontillo

Reputation: 13947

The PLT is the Procedure Linkage Table. See the documentation here. This is used for lazy loading of function references.

Is it always stuck here? Pure conjecture here, but if so, that might indicate that the function remains unresolved. For example, if an expected library isn't loaded.

And yes, the hex numbers typically indicate the value of the instruction pointer pushed onto the stack. You could verify this with the l * <address> command, to tell GDB to list the line of code at that address. Or just use the f <frame#> command to switch to that stack frame.

Try looking at /proc/<pid>/maps (where <pid> is the PID for this process) and see if the library that you expect talloc_free to be in is loaded.

Upvotes: 3

Daniel Santos
Daniel Santos

Reputation: 3295

I'm pretty certain that "@plt" is part of the name mangling. And yes, the 2nd column is your address. So you can type "finish" now and if gdb doesn't take you back to a prompt in short order, then that means your infinite loop is occurring in talloc's free. This could either be a bug in the talloc library (which I've never used) or, more likely, you've corrupted your heap. You'll often find that when using glibc, it will detect heap corruption and give you a pretty crash message.

I would recommend you run your program in valgrind -- it's a nice way to quickly detect memory errors.

Upvotes: 0

Related Questions