From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32485 invoked by alias); 28 Mar 2006 10:43:51 -0000 Received: (qmail 32474 invoked by uid 22791); 28 Mar 2006 10:43:51 -0000 X-Spam-Check-By: sourceware.org Received: from balabit.hu (HELO balabit.hu) (195.70.34.196) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 28 Mar 2006 10:43:49 +0000 Subject: thread register state information invalid in core files From: Balazs Scheidler To: gdb@sourceware.org Content-Type: text/plain Date: Tue, 28 Mar 2006 14:36:00 -0000 Message-Id: <1143542626.8742.12.camel@bzorp.balabit> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00184.txt.bz2 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