From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32543 invoked by alias); 13 Mar 2007 04:07:45 -0000 Received: (qmail 32481 invoked by uid 22791); 13 Mar 2007 04:07:44 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 13 Mar 2007 04:07:31 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id CECFC48CE16; Tue, 13 Mar 2007 00:07:29 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03679-01-2; Mon, 12 Mar 2007 23:07:29 -0500 (EST) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 784A548CDFD; Tue, 13 Mar 2007 00:07:29 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id 3CEFFE7B38; Mon, 12 Mar 2007 21:08:04 -0700 (PDT) Date: Tue, 13 Mar 2007 04:07:00 -0000 From: Joel Brobecker To: Rich Rattanni Cc: Michael Snyder , gdb@sourceware.org Subject: Re: Cause of the ?? in backtrace Message-ID: <20070313040804.GQ14401@adacore.com> References: <3187bd480703120747h332fbf12gab39d77719c910f9@mail.gmail.com> <1173744387.11051.24.camel@localhost.localdomain> <3187bd480703122048v4b1482f0n1cffd1f473af5193@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3187bd480703122048v4b1482f0n1cffd1f473af5193@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00182.txt.bz2 > 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 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