Bug 9276 - No backtrace generated on amd64 with a PIE executable
Summary: No backtrace generated on amd64 with a PIE executable
Status: RESOLVED DUPLICATE of bug 9174
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 6.5
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-16 00:08 UTC by madcoder
Modified: 2009-03-08 05:49 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description madcoder 2006-09-16 00:08:01 UTC
[Converted from Gnats 2171]

I've compiled an application (php) with debugging symbols, yet when I run it through gdb on an amd64 machine, I only get the memory addresses, no useful information.  I have verified that debugging symbols are in fact compiled into the binaries:

> # file /usr/lib64/php5/bin/php
> /usr/lib64/php5/bin/php: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.1, __not stripped__

And the coredump has debugging symbols in it:

> # strings core | grep zend
> zend_version
> zend_thread_safe
> zend_version
> (etc...)

Yet when I run the core through gdb this is what I get:

> # gdb php core
> GNU gdb 6.5
> This GDB was configured as "x86_64-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
> Core was generated by `php -e test.php'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x00002aaaac8d1e44 in ?? ()
> (gdb) thread apply bt all
> (gdb) bt
> #0  0x00002aaaac8d1e44 in ?? ()
> #1  0x00000000559d27f0 in ?? ()
> #2  0x0000555555f73cb0 in ?? ()
> (etc...)

I can't get a useful backtrace from this in order to file a bug report with PHP.  PHP was configured with --enable-debug, and compiled with -g (also tried -g2 and -ggdb), and nothing has worked.

Release:
GNU gdb 6.5

Environment:
Linux elpdat01 2.6.15-gentoo-r5 #4 SMP Fri Aug 11 21:15:18 MDT 2006 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ GNU/Linux
-----
Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/specs
Configured with: /var/tmp/portage/gcc-3.4.6-r1/work/gcc-3.4.6/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.6 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.6 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.6/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.6/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/include/g++-v3 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --enable-multilib --disable-libgcj --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.6 (Gentoo Hardened 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
-----
This GDB was configured as "x86_64-pc-linux-gnu".

How-To-Repeat:
Consistent.  Run php via gdb, or run a php core file through gdb.
Comment 1 madcoder 2006-09-16 00:08:01 UTC
Fix:
Yes please :)
Comment 2 drow@false.org 2006-09-16 00:12:43 UTC
From: Daniel Jacobowitz <drow@false.org>
To: madcoder@gmail.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2171: No backtrace generated on amd64
Date: Fri, 15 Sep 2006 20:12:43 -0400

 On Sat, Sep 16, 2006 at 12:05:32AM -0000, madcoder@gmail.com wrote:
 > And the coredump has debugging symbols in it:
 
 Core dumps do not contain real symbol information.
 
 > > # gdb php core
 > > GNU gdb 6.5
 > > This GDB was configured as "x86_64-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
 > > Core was generated by `php -e test.php'.
 > > Program terminated with signal 11, Segmentation fault.
 > > #0  0x00002aaaac8d1e44 in ?? ()
 
 This is a shared library address.  Does info shared work?  It looks
 like your system libraries are undebuggable, not the binary itself.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

Comment 3 madcoder 2006-09-16 07:15:28 UTC
From: "Joe Hansche" <madcoder@gmail.com>
To: "Daniel Jacobowitz" <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2171: No backtrace generated on amd64
Date: Sat, 16 Sep 2006 01:15:28 -0600

 > Core dumps do not contain real symbol information.
 
 Sorry, I was just pointing out that it had the names of functions,
 which is what I would expect in the backtrace.
 
 > This is a shared library address.  Does info shared work?  It looks
 > like your system libraries are undebuggable, not the binary itself.
 
 (gdb) info shared
 No shared libraries loaded at this time.
 
 Which system libraries are you refering to?  I'm trying to get a
 backtrace from the php process.  The binary has debugging symbols.  Is
 there no way to get a backtrace with that?  What can I do to get a
 backtrace (either from shared libraries, or the php binary itself)?
 
 Thanks,
 Joe
 
 
 On 9/15/06, Daniel Jacobowitz <drow@false.org> wrote:
 > On Sat, Sep 16, 2006 at 12:05:32AM -0000, madcoder@gmail.com wrote:
 > > And the coredump has debugging symbols in it:
 >
 > Core dumps do not contain real symbol information.
 >
 > > > # gdb php core
 > > > GNU gdb 6.5
 > > > This GDB was configured as "x86_64-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
 > > > Core was generated by `php -e test.php'.
 > > > Program terminated with signal 11, Segmentation fault.
 > > > #0  0x00002aaaac8d1e44 in ?? ()
 >
 > This is a shared library address.  Does info shared work?  It looks
 > like your system libraries are undebuggable, not the binary itself.
 >
 > --
 > Daniel Jacobowitz
 > CodeSourcery
 >

Comment 4 drow@false.org 2006-09-16 20:26:53 UTC
From: Daniel Jacobowitz <drow@false.org>
To: Joe Hansche <madcoder@gmail.com>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2171: No backtrace generated on amd64
Date: Sat, 16 Sep 2006 16:26:53 -0400

 On Sat, Sep 16, 2006 at 01:15:28AM -0600, Joe Hansche wrote:
 > >This is a shared library address.  Does info shared work?  It looks
 > >like your system libraries are undebuggable, not the binary itself.
 > 
 > (gdb) info shared
 > No shared libraries loaded at this time.
 
 Is PHP dynamically linked?  If it is, I can only assume that either
 your kernel produces broken core dumps - this happens from time to time
 - or that something is very badly wrong with your GDB.
 
 Take a look with readelf -l at the php binary and the core file.
 The binary should have a DYNAMIC entry.  Do any of the LOAD entries for
 the core file cover that same address region?  If so, do they have
 non-zero values in FileSiz?
 
 My suspicion is that you have one of the broken kernel versions, which
 fails to dump sections if they are modified and then mprotect'd to
 readonly.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

Comment 5 madcoder 2006-09-16 20:36:52 UTC
From: "Joe Hansche" <madcoder@gmail.com>
To: "Daniel Jacobowitz" <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2171: No backtrace generated on amd64
Date: Sat, 16 Sep 2006 14:36:52 -0600

 > Is PHP dynamically linked?
 Yes
 
 > If it is, I can only assume that either
 > your kernel produces broken core dumps - this happens from time to time
 > - or that something is very badly wrong with your GDB.
 >
 > Take a look with readelf -l at the php binary and the core file.
 > The binary should have a DYNAMIC entry.  Do any of the LOAD entries for
 > the core file cover that same address region?  If so, do they have
 > non-zero values in FileSiz?
 
 # readelf -l /usr/lib64/php5/bin/php | grep DYNAMIC
   DYNAMIC        0x0000000000535070 0x0000000000635070 0x0000000000635070
 
 # readelf -l core
 ...
   LOAD           0x0000000000053000 0x00002aaaab546000 0x0000000000000000
                  0x0000000000000000 0x0000000000064000  R E    1000
   LOAD           0x0000000000053000 0x00002aaaab5aa000 0x0000000000000000
                  0x0000000000000000 0x0000000000100000         1000
   LOAD           0x0000000000053000 0x00002aaaab6aa000 0x0000000000000000
                  0x0000000000006000 0x0000000000006000  RW     1000
 ...
 
 Would that be considered "covering the same region"?  There aren't any
 entries that have identical values.  (the 3rd entry there, with RW,
 has the non-zero FileSiz)
 
 > My suspicion is that you have one of the broken kernel versions, which
 > fails to dump sections if they are modified and then mprotect'd to
 > readonly.
 
 Would that be a specific kernel version, or something compiled into
 the kernel, which breaks that?  If it's the kernel version, would you
 happen to know which kernel is known to behave properly, or would you
 know of anything that is known to cause this behavior when compiled
 into the kernel?  I can compile a new kernel if you think it will make
 a difference.
 
 #uname -a
 Linux elpdat01 2.6.15-gentoo-r5 #4 SMP Fri Aug 11 21:15:18 MDT 2006
 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ GNU/Linux
 
 
 Thanks a lot for your help - it is a ppreciated.
 -Joe
 
 > --
 > Daniel Jacobowitz
 > CodeSourcery
 >

Comment 6 drow@false.org 2006-09-17 22:48:00 UTC
From: Daniel Jacobowitz <drow@false.org>
To: Joe Hansche <madcoder@gmail.com>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2171: No backtrace generated on amd64
Date: Sun, 17 Sep 2006 18:48:00 -0400

 On Sat, Sep 16, 2006 at 02:36:52PM -0600, Joe Hansche wrote:
 > >Take a look with readelf -l at the php binary and the core file.
 > >The binary should have a DYNAMIC entry.  Do any of the LOAD entries for
 > >the core file cover that same address region?  If so, do they have
 > >non-zero values in FileSiz?
 
 > # readelf -l /usr/lib64/php5/bin/php | grep DYNAMIC
 >  DYNAMIC        0x0000000000535070 0x0000000000635070 0x0000000000635070
 > 
 > # readelf -l core
 > ...
 >  LOAD           0x0000000000053000 0x00002aaaab546000 0x0000000000000000
 >                 0x0000000000000000 0x0000000000064000  R E    1000
 >  LOAD           0x0000000000053000 0x00002aaaab5aa000 0x0000000000000000
 >                 0x0000000000000000 0x0000000000100000         1000
 >  LOAD           0x0000000000053000 0x00002aaaab6aa000 0x0000000000000000
 >                 0x0000000000006000 0x0000000000006000  RW     1000
 > ...
 > 
 > Would that be considered "covering the same region"?  There aren't any
 > entries that have identical values.  (the 3rd entry there, with RW,
 > has the non-zero FileSiz)
 
 Sorry, I wasn't clear enough - neither these nor your later
 off-list message are the right entries.  The first column is a physical
 file offset, and is not particularly interesting.  The intersting bit
 is the second column: virtual address, e.g. 0x0000000000635070.  Is
 that covered by any LOAD?
 
 > Would that be a specific kernel version, or something compiled into
 > the kernel, which breaks that?  If it's the kernel version, would you
 > happen to know which kernel is known to behave properly, or would you
 > know of anything that is known to cause this behavior when compiled
 > into the kernel?  I can compile a new kernel if you think it will make
 > a difference.
 
 It'd be a kernel version, but I don't remember which.  I think 2.6.15
 is far too new to have the problem, but I don't remember for sure.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

Comment 7 madcoder 2006-09-17 23:04:13 UTC
From: "Joe Hansche" <madcoder@gmail.com>
To: "Daniel Jacobowitz" <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2171: No backtrace generated on amd64
Date: Sun, 17 Sep 2006 17:04:13 -0600

 > Sorry, I wasn't clear enough - neither these nor your later
 > off-list message are the right entries.  The first column is a physical
 > file offset, and is not particularly interesting.  The intersting bit
 > is the second column: virtual address, e.g. 0x0000000000635070.  Is
 > that covered by any LOAD?
 
 The first LOAD entry has a VirtAddr value of 0x00002aaaaaaab000, and
 the values continue to increase until 0x00007fffff7fa000.  So, all of
 the values from the coredump are far above the value from the PHP
 binary: 0x0000000000635070.  I'm sorry I don't quite know what that
 means in my case.  Would it be more likely that it's a problem with my
 PHP, gdb, or kernel?  Any suggestions I should try? I can attach my
 kernel config if it will be helpful?
 
 Thanks,
 Joe
 
 > It'd be a kernel version, but I don't remember which.  I think 2.6.15
 > is far too new to have the problem, but I don't remember for sure.
 >
 > --
 > Daniel Jacobowitz
 > CodeSourcery
 >

Comment 8 drow@false.org 2006-09-18 00:02:39 UTC
From: Daniel Jacobowitz <drow@false.org>
To: Joe Hansche <madcoder@gmail.com>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2171: No backtrace generated on amd64
Date: Sun, 17 Sep 2006 20:02:39 -0400

 On Sun, Sep 17, 2006 at 05:04:13PM -0600, Joe Hansche wrote:
 > The first LOAD entry has a VirtAddr value of 0x00002aaaaaaab000, and
 > the values continue to increase until 0x00007fffff7fa000.  So, all of
 > the values from the coredump are far above the value from the PHP
 > binary: 0x0000000000635070.  I'm sorry I don't quite know what that
 > means in my case.  Would it be more likely that it's a problem with my
 > PHP, gdb, or kernel?  Any suggestions I should try? I can attach my
 > kernel config if it will be helpful?
 
 It wouldn't be helpful.  I can only guess that the kernel is at fault.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

Comment 9 madcoder 2006-09-18 12:21:40 UTC
From: "Joe Hansche" <madcoder@gmail.com>
To: "Daniel Jacobowitz" <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2171: No backtrace generated on amd64
Date: Mon, 18 Sep 2006 06:21:40 -0600

 I've upgraded to kernel version 2.6.17, with the same results (after
 recompiling both gdb and php).  I tried looking through the kernel
 .config to see what might cause something like this.  The only thing I
 ended up changing, aside from the defaults in the new kernel, was
 changing the memory model from Discontiguous to Sparse.
 
 Any more ideas?  Or since you are saying it looks like a kernel
 problem, where should I look for more information on this?
 
 Thanks again,
 Joe
 
 On 9/17/06, Daniel Jacobowitz <drow@false.org> wrote:
 > On Sun, Sep 17, 2006 at 05:04:13PM -0600, Joe Hansche wrote:
 > > The first LOAD entry has a VirtAddr value of 0x00002aaaaaaab000, and
 > > the values continue to increase until 0x00007fffff7fa000.  So, all of
 > > the values from the coredump are far above the value from the PHP
 > > binary: 0x0000000000635070.  I'm sorry I don't quite know what that
 > > means in my case.  Would it be more likely that it's a problem with my
 > > PHP, gdb, or kernel?  Any suggestions I should try? I can attach my
 > > kernel config if it will be helpful?
 >
 > It wouldn't be helpful.  I can only guess that the kernel is at fault.
 >
 > --
 > Daniel Jacobowitz
 > CodeSourcery
 >

Comment 10 drow@false.org 2006-09-18 13:49:19 UTC
From: Daniel Jacobowitz <drow@false.org>
To: Joe Hansche <madcoder@gmail.com>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2171: No backtrace generated on amd64
Date: Mon, 18 Sep 2006 09:49:19 -0400

 On Mon, Sep 18, 2006 at 06:21:40AM -0600, Joe Hansche wrote:
 > I've upgraded to kernel version 2.6.17, with the same results (after
 > recompiling both gdb and php).  I tried looking through the kernel
 > .config to see what might cause something like this.  The only thing I
 > ended up changing, aside from the defaults in the new kernel, was
 > changing the memory model from Discontiguous to Sparse.
 > 
 > Any more ideas?  Or since you are saying it looks like a kernel
 > problem, where should I look for more information on this?
 
 Sorry, I'm stumped.  Do you want to try sending me the php binary and
 core file, compressed?  If it's too large I can give you an FTP site
 to upload them to.  Please don't try sending anything that large to the
 lists or bug tracker, though.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

Comment 11 drow@false.org 2006-09-18 18:05:37 UTC
From: Daniel Jacobowitz <drow@false.org>
To: Joe Hansche <madcoder@gmail.com>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2171: No backtrace generated on amd64
Date: Mon, 18 Sep 2006 14:05:37 -0400

 On Mon, Sep 18, 2006 at 06:21:40AM -0600, Joe Hansche wrote:
 > I've upgraded to kernel version 2.6.17, with the same results (after
 > recompiling both gdb and php).  I tried looking through the kernel
 > .config to see what might cause something like this.  The only thing I
 > ended up changing, aside from the defaults in the new kernel, was
 > changing the memory model from Discontiguous to Sparse.
 > 
 > Any more ideas?  Or since you are saying it looks like a kernel
 > problem, where should I look for more information on this?
 
 drow@caradoc:~/nevyn-home/z% readelf -l php | head
 
 Elf file type is DYN (Shared object file)
 
 There we go.  This is PIE, a position independent executable.  The FSF
 GDB does not support PIE.
 
 I believe Red Hat ships some unsubmitted patches for this issue; they
 were mentioned on the gdb mailing list a few weeks ago.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery

Comment 12 madcoder 2006-09-18 23:32:36 UTC
From: "Joe Hansche" <madcoder@gmail.com>
To: "Daniel Jacobowitz" <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2171: No backtrace generated on amd64 [SOLVED]
Date: Mon, 18 Sep 2006 17:32:36 -0600

 Yep, that was it, thanks!  Turns out gentoo included those pie patches
 up through version 6.3, then for some reason, the patches are no
 longer included.  I downgraded gdb to 6.3, and it works fine.
 
 Thanks again for all your help.
 Joe
 
 On 9/18/06, Daniel Jacobowitz <drow@false.org> wrote:
 > On Mon, Sep 18, 2006 at 06:21:40AM -0600, Joe Hansche wrote:
 > > I've upgraded to kernel version 2.6.17, with the same results (after
 > > recompiling both gdb and php).  I tried looking through the kernel
 > > .config to see what might cause something like this.  The only thing I
 > > ended up changing, aside from the defaults in the new kernel, was
 > > changing the memory model from Discontiguous to Sparse.
 > >
 > > Any more ideas?  Or since you are saying it looks like a kernel
 > > problem, where should I look for more information on this?
 >
 > drow@caradoc:~/nevyn-home/z% readelf -l php | head
 >
 > Elf file type is DYN (Shared object file)
 >
 > There we go.  This is PIE, a position independent executable.  The FSF
 > GDB does not support PIE.
 >
 > I believe Red Hat ships some unsubmitted patches for this issue; they
 > were mentioned on the gdb mailing list a few weeks ago.
 >
 > --
 > Daniel Jacobowitz
 > CodeSourcery
 >
Comment 13 Thiago Jung Bauermann 2009-03-08 05:46:49 UTC

*** This bug has been marked as a duplicate of 9174 ***
Comment 14 Thiago Jung Bauermann 2009-03-08 05:49:57 UTC
Madcoder,

FYI: I didn't add you to the Cc: list of bug #9174 because you seem to be happy
with the workaround you found. Feel free to add yourself there if you want.