This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: thread register state information invalid in core files
- From: Daniel Jacobowitz <drow at false dot org>
- To: Balazs Scheidler <bazsi at balabit dot hu>
- Cc: gdb at sourceware dot org
- Date: Tue, 28 Mar 2006 09:36:47 -0500
- Subject: Re: thread register state information invalid in core files
- References: <1143542626.8742.12.camel@bzorp.balabit>
On Tue, Mar 28, 2006 at 12:43:45PM +0200, Balazs Scheidler wrote:
> Anything else:
> (gdb) thread 2
> [Switching to thread 2 (process 26119)]#0 0x00010202 in ?? ()
> (gdb) bt
> #0 0x00010202 in ?? ()
> Cannot access memory at address 0x0
> (gdb) info registers
> eax 0xc010007b -1072693125
> ecx 0x243948 2373960
> edx 0x0 0
> ebx 0x1f8 504
> esp 0x0 0x0
> ebp 0x7b 0x7b
> esi 0x409272c 67708716
> edi 0x243900 2373888
> eip 0x10202 0x10202
> eflags 0x7b 123
> cs 0x26f4 9972
> ss 0x0 0
> ds 0xffff 65535
> es 0x3965 14693
> fs 0x0 0
> gs 0x33 51
>
> Looking at the value of ESP and EBP it is possible that gdb incorrectly
> reads the stack-frame information.
It looks to me like the core file is just corrupt.
These registers are in the pseudo-sections you saw in objdump, in the
order the header files describe for an elf_gregset_t. You may want to
check the core file by hand; you can dump the sections using objdump -s
-j "sectionname".
I remember having various problems with threaded core dumps in recent
kernels.
> The funny part that the segfault
> itself occurred in the PID number 31158 (not the main thread for sure),
> but gdb lists pid 31158 as the main thread with the main thread's stack.
The kernel always dumps the faulting thread first.
--
Daniel Jacobowitz
CodeSourcery