Cause of the ?? in backtrace

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)

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

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.Snyderpalmsource.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.
>
>

> 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.Snyderpalmsource.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

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.

Joel Brobecker <brobeckeradacore.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, schwabsuse.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."