From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11378 invoked by alias); 28 Mar 2006 14:36:51 -0000 Received: (qmail 11369 invoked by uid 22791); 28 Mar 2006 14:36:50 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 28 Mar 2006 14:36:49 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FOFJP-0007zE-On; Tue, 28 Mar 2006 09:36:47 -0500 Date: Tue, 28 Mar 2006 15:31:00 -0000 From: Daniel Jacobowitz To: Balazs Scheidler Cc: gdb@sourceware.org Subject: Re: thread register state information invalid in core files Message-ID: <20060328143647.GB30581@nevyn.them.org> Mail-Followup-To: Balazs Scheidler , gdb@sourceware.org References: <1143542626.8742.12.camel@bzorp.balabit> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1143542626.8742.12.camel@bzorp.balabit> User-Agent: Mutt/1.5.8i 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/msg00186.txt.bz2 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