This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: gdb/2171: No backtrace generated on amd64
- From: "Joe Hansche" <madcoder at gmail dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 16 Sep 2006 20:38:01 -0000
- Subject: Re: gdb/2171: No backtrace generated on amd64
- Reply-to: "Joe Hansche" <madcoder at gmail dot com>
The following reply was made to PR gdb/2171; it has been noted by GNATS.
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
>