This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [ARM][GDB] backtrace does not go beyond libc functions
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Sundar Dev <sundarjdevml at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 29 Jun 2015 10:30:52 +0100
- Subject: Re: [ARM][GDB] backtrace does not go beyond libc functions
- Authentication-results: sourceware.org; auth=none
- References: <CAHOCAJYDEs-E2mReG5psMmDX96gNB0XjhGP4=0rpOhXM2Kyd_Q at mail dot gmail dot com>
Sundar Dev <sundarjdevml@gmail.com> writes:
> function like poll(), read(), etc., and I attach a remote gdbserver to
> the process and try to get backtrace, all I see is the following 4
> backtrace frames as shown below-
> (gdb) bt
> #0 0x758b9190 in poll () from /lib/libc.so.6
> #1 0x758b9184 in poll () from /lib/libc.so.6
> #2 0x013df120 in ?? ()
> #3 0x013df120 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> And address 0x013df120 is in the heap region in proc/<pid>/maps (shown
> below) of my process-
> root@xyz# cat /proc/621/maps
> ...<snip>...
> 01389000-0154e000 rw-p 00000000 00:00 0 [heap]
> ...<snip>...
>
The address 0x013df120 in frame #2 is got from frame #1 by unwinding.
The unwinding can be wrong, so address 0x013df120 can be wrong too.
> I've looked at gdb source code and I know that the version of gdb that I'm using
> (7.6.2) has support to backtrace using ARM unwind tables and frame
> pointers (see [1] and [2]). But, even then, all I get from GDB
> backtrace is the above shown output. Does anybody here have any
> comments and/or suggestions?
I don't have much suggestions to give, unless I can reproduce it. GDB
tries different unwinders to unwind a certain frame, which means
exception table unwinder may be used or may not be used. You can debug
GDB to see which unwinder is used, and identify why the bad pc
(0x013df120) is got from the unwinding.
--
Yao (éå)