Cause of the ?? in backtrace

Cause of the ?? in backtrace

[Rich Rattanni]

Why would one get the following when trying to do a backtrace in GDB...
(gdb) bt
#0  0x403cdcb4 in _int_malloc () from /lib/libc.so.6
#1  0x403cedfc in malloc () from /lib/libc.so.6
#2  0x401c4418 in sqlite3MallocRaw () from /usr/lib/libsqlite3.so.0
#3  0x401c450c in sqlite3StrNDup () from /usr/lib/libsqlite3.so.0
#4  0x401cc070 in sqlite3VdbeChangeP3 () from /usr/lib/libsqlite3.so.0
#5  0x401cc0ac in sqlite3VdbeOp3 () from /usr/lib/libsqlite3.so.0
#6  0x401ac010 in sqlite3CodeSubselect () from /usr/lib/libsqlite3.so.0
#7  0x401ab4b0 in sqlite3ExprCode () from /usr/lib/libsqlite3.so.0
#8  0x401abd00 in sqlite3ExprIfFalse () from /usr/lib/libsqlite3.so.0
#9  0x401d02cc in sqlite3WhereBegin () from /usr/lib/libsqlite3.so.0
#10 0x401bf13c in sqlite3Select () from /usr/lib/libsqlite3.so.0
#11 0x401b6978 in sqlite3Parser () from /usr/lib/libsqlite3.so.0
#12 0x401c12e0 in sqlite3RunParser () from /usr/lib/libsqlite3.so.0
#13 0x47de97e0 in ?? ()        <------------------------------- This
is my problem
Cannot access memory at address 0x30  <------------|
(gdb)

Re: Cause of the ?? in backtrace

[Daniel Jacobowitz]

On Mon, Mar 12, 2007 at 10:47:54AM -0400, Rich Rattanni wrote:
> Why would one get the following when trying to do a backtrace in GDB...

Because GDB could not figure out what came next.  The library might be
too optimized and stripped, or the stack might be corrupt, or GDB
might have a bug, or some other operating system specific problem.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Cause of the ?? in backtrace

[Michael Snyder]

On Mon, 2007-03-12 at 10:47 -0400, Rich Rattanni wrote:
> Why would one get the following when trying to do a backtrace in GDB...
> (gdb) bt
> #0  0x403cdcb4 in _int_malloc () from /lib/libc.so.6
> #1  0x403cedfc in malloc () from /lib/libc.so.6
> #2  0x401c4418 in sqlite3MallocRaw () from /usr/lib/libsqlite3.so.0
> #3  0x401c450c in sqlite3StrNDup () from /usr/lib/libsqlite3.so.0
> #4  0x401cc070 in sqlite3VdbeChangeP3 () from /usr/lib/libsqlite3.so.0
> #5  0x401cc0ac in sqlite3VdbeOp3 () from /usr/lib/libsqlite3.so.0
> #6  0x401ac010 in sqlite3CodeSubselect () from /usr/lib/libsqlite3.so.0
> #7  0x401ab4b0 in sqlite3ExprCode () from /usr/lib/libsqlite3.so.0
> #8  0x401abd00 in sqlite3ExprIfFalse () from /usr/lib/libsqlite3.so.0
> #9  0x401d02cc in sqlite3WhereBegin () from /usr/lib/libsqlite3.so.0
> #10 0x401bf13c in sqlite3Select () from /usr/lib/libsqlite3.so.0
> #11 0x401b6978 in sqlite3Parser () from /usr/lib/libsqlite3.so.0
> #12 0x401c12e0 in sqlite3RunParser () from /usr/lib/libsqlite3.so.0
> #13 0x47de97e0 in ?? ()        <------------------------------- This
> is my problem


Specifically, the ?? means that gdb could not find a symbol to 
correspond with the instruction address 0x47de97e0.  This might
mean any number of things.

If the address is legitimate (ie. the return address of sqlite3RunParser
really does point back to a caller at 0x47de97e0), then this caller 
may be from a library for which gdb has no symbols.  It might be 
self-generating code, in which case it may never have had any
symbols.

Or the address may NOT be legitimate, and may have come about 
as a result of a corrupted stack or something.

Re: Cause of the ?? in backtrace

[Rich Rattanni]

In order to ensure the library has debug info built into it, do you
just need to build the library with the -g option specified during
compilation?  Or is it more involved?

On 3/12/07, Michael Snyder <Michael.Snyder@palmsource.com> wrote:
> On Mon, 2007-03-12 at 10:47 -0400, Rich Rattanni wrote:
> > Why would one get the following when trying to do a backtrace in GDB...
> > (gdb) bt
> > #0  0x403cdcb4 in _int_malloc () from /lib/libc.so.6
> > #1  0x403cedfc in malloc () from /lib/libc.so.6
> > #2  0x401c4418 in sqlite3MallocRaw () from /usr/lib/libsqlite3.so.0
> > #3  0x401c450c in sqlite3StrNDup () from /usr/lib/libsqlite3.so.0
> > #4  0x401cc070 in sqlite3VdbeChangeP3 () from /usr/lib/libsqlite3.so.0
> > #5  0x401cc0ac in sqlite3VdbeOp3 () from /usr/lib/libsqlite3.so.0
> > #6  0x401ac010 in sqlite3CodeSubselect () from /usr/lib/libsqlite3.so.0
> > #7  0x401ab4b0 in sqlite3ExprCode () from /usr/lib/libsqlite3.so.0
> > #8  0x401abd00 in sqlite3ExprIfFalse () from /usr/lib/libsqlite3.so.0
> > #9  0x401d02cc in sqlite3WhereBegin () from /usr/lib/libsqlite3.so.0
> > #10 0x401bf13c in sqlite3Select () from /usr/lib/libsqlite3.so.0
> > #11 0x401b6978 in sqlite3Parser () from /usr/lib/libsqlite3.so.0
> > #12 0x401c12e0 in sqlite3RunParser () from /usr/lib/libsqlite3.so.0
> > #13 0x47de97e0 in ?? ()        <------------------------------- This
> > is my problem
>
>
> Specifically, the ?? means that gdb could not find a symbol to
> correspond with the instruction address 0x47de97e0.  This might
> mean any number of things.
>
> If the address is legitimate (ie. the return address of sqlite3RunParser
> really does point back to a caller at 0x47de97e0), then this caller
> may be from a library for which gdb has no symbols.  It might be
> self-generating code, in which case it may never have had any
> symbols.
>
> Or the address may NOT be legitimate, and may have come about
> as a result of a corrupted stack or something.
>
>

Re: Cause of the ?? in backtrace

[Joel Brobecker]

> In order to ensure the library has debug info built into it, do you
> just need to build the library with the -g option specified during
> compilation?  Or is it more involved?

Building it with -g should be sufficient. However, even if the library
was not built with debug info, we should still have the symbol table
to work with, right?

One thing you can do to confirm whether the address is legitimate or
not, is check the instruction just before 0x47de97e0 (that's the
return address). If it is not a jump or a call, then I'm pretty
sure the problem is in the computing of that return address...

> On 3/12/07, Michael Snyder <Michael.Snyder@palmsource.com> wrote:
> >On Mon, 2007-03-12 at 10:47 -0400, Rich Rattanni wrote:
> >> Why would one get the following when trying to do a backtrace in GDB...
> >> (gdb) bt
> >> #0  0x403cdcb4 in _int_malloc () from /lib/libc.so.6
> >> #1  0x403cedfc in malloc () from /lib/libc.so.6
> >> #2  0x401c4418 in sqlite3MallocRaw () from /usr/lib/libsqlite3.so.0
> >> #3  0x401c450c in sqlite3StrNDup () from /usr/lib/libsqlite3.so.0
> >> #4  0x401cc070 in sqlite3VdbeChangeP3 () from /usr/lib/libsqlite3.so.0
> >> #5  0x401cc0ac in sqlite3VdbeOp3 () from /usr/lib/libsqlite3.so.0
> >> #6  0x401ac010 in sqlite3CodeSubselect () from /usr/lib/libsqlite3.so.0
> >> #7  0x401ab4b0 in sqlite3ExprCode () from /usr/lib/libsqlite3.so.0
> >> #8  0x401abd00 in sqlite3ExprIfFalse () from /usr/lib/libsqlite3.so.0
> >> #9  0x401d02cc in sqlite3WhereBegin () from /usr/lib/libsqlite3.so.0
> >> #10 0x401bf13c in sqlite3Select () from /usr/lib/libsqlite3.so.0
> >> #11 0x401b6978 in sqlite3Parser () from /usr/lib/libsqlite3.so.0
> >> #12 0x401c12e0 in sqlite3RunParser () from /usr/lib/libsqlite3.so.0
> >> #13 0x47de97e0 in ?? ()        <------------------------------- This
> >> is my problem

-- 
Joel

Re: Cause of the ?? in backtrace

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

>> In order to ensure the library has debug info built into it, do you
>> just need to build the library with the -g option specified during
>> compilation?  Or is it more involved?
>
> Building it with -g should be sufficient. However, even if the library
> was not built with debug info, we should still have the symbol table
> to work with, right?

Unless it is stripped.  The dynamic symbol table may not be enough.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Cause of the ?? in backtrace

[Bin Chen]

Rich Rattanni 写道:
> Why would one get the following when trying to do a backtrace in GDB...
> (gdb) bt
> #0 0x403cdcb4 in _int_malloc () from /lib/libc.so.6
> #1 0x403cedfc in malloc () from /lib/libc.so.6
> #2 0x401c4418 in sqlite3MallocRaw () from /usr/lib/libsqlite3.so.0
> #3 0x401c450c in sqlite3StrNDup () from /usr/lib/libsqlite3.so.0
> #4 0x401cc070 in sqlite3VdbeChangeP3 () from /usr/lib/libsqlite3.so.0
> #5 0x401cc0ac in sqlite3VdbeOp3 () from /usr/lib/libsqlite3.so.0
> #6 0x401ac010 in sqlite3CodeSubselect () from /usr/lib/libsqlite3.so.0
> #7 0x401ab4b0 in sqlite3ExprCode () from /usr/lib/libsqlite3.so.0
> #8 0x401abd00 in sqlite3ExprIfFalse () from /usr/lib/libsqlite3.so.0
> #9 0x401d02cc in sqlite3WhereBegin () from /usr/lib/libsqlite3.so.0
> #10 0x401bf13c in sqlite3Select () from /usr/lib/libsqlite3.so.0
> #11 0x401b6978 in sqlite3Parser () from /usr/lib/libsqlite3.so.0
> #12 0x401c12e0 in sqlite3RunParser () from /usr/lib/libsqlite3.so.0
> #13 0x47de97e0 in ?? () <------------------------------- This
> is my problem
> Cannot access memory at address 0x30 <------------|
> (gdb)
>
Just FYI. Last time I encounter such problem and I found that it is not 
caused with your private code didn't compile with -g, but is caused by 
your common libc related library didn't contain the debug info.