thread register state information invalid in core files

[Balazs Scheidler <bazsi@balabit.hu>]

Hi,

I have tried to analyze a core file generated by Linux kernel 2.6.12
(x86 processor, basically Debian sarge), without much success.

Gdb correctly shows the list of threads in the application, but apart
from the main thread, the backtrace information is unusable.

Main thread:
(gdb) thread 1
[Switching to thread 1 (process 31158)]#0  0x001e0523 in poll () from /lib/tls/libc.so.6
(gdb) bt
#0  0x001e0523 in poll () from /lib/tls/libc.so.6
#1  0x00688296 in g_main_loop_get_context () from /usr/lib/libglib-2.0.so.0
#2  0x00687890 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#3  0x00687b5d in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#4  0x005ad689 in z_main_loop (policy_file=0x8065240 "/etc/zorp/policy.py", instance_name=0x8064fe8 "intra_http", instance_policy_list=0x804c460) at zorp.c:165
#5  0x0804a2d8 in main (argc=1, argv=0xbffff9e4) at main.c:435
#6  0x00126974 in __libc_start_main () from /lib/tls/libc.so.6
#7  0x08049831 in _start () at ../sysdeps/i386/elf/start.S:102

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. 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.

Lucky me I have some information based on the system log, and I know the
address of the stackframe where the segfault occurred. If only 
"frame *address" worked, I could unwind the stack easily, but it does
not.

I have looked at the core file using objdump, and it does seem to
contain information on various threads:

  1 .reg/31158    00000044  00000000  00000000  00002110  2**2
                  CONTENTS
  2 .reg          00000044  00000000  00000000  00002110  2**2
                  CONTENTS
  3 .auxv         00000090  00000000  00000000  00002730  2**2
                  CONTENTS
  4 .reg2/31158   0000006c  00000000  00000000  000027d4  2**2
                  CONTENTS
  5 .reg2         0000006c  00000000  00000000  000027d4  2**2
                  CONTENTS
  6 .reg-xfp/31158 00000200  00000000  00000000  00002854  2**2
                  CONTENTS
  7 .reg-xfp      00000200  00000000  00000000  00002854  2**2
                  CONTENTS
  8 .reg/26119    00000044  00000000  00000000  00002ab0  2**2
                  CONTENTS
  9 .reg2/26119   0000006c  00000000  00000000  00002b0c  2**2
                  CONTENTS
 10 .reg-xfp/26119 00000200  00000000  00000000  00002b8c  2**2
                  CONTENTS
 11 .reg/26108    00000044  00000000  00000000  00002de8  2**2
                  CONTENTS
 12 .reg2/26108   0000006c  00000000  00000000  00002e44  2**2
                  CONTENTS
 13 .reg-xfp/26108 00000200  00000000  00000000  00002ec4  2**2
                  CONTENTS

But as I'm not fluent in core file structure I'm stumped. All this
applies to gdb 6.3. I've just finished compiling gdb 6.4 but it shows
the same symptoms.

Any help?

-- 
Bazsi