Re: thread register state information invalid in core files

[Daniel Jacobowitz <drow@false.org>]

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