From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22723 invoked by alias); 16 Apr 2002 18:16:12 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 22592 invoked from network); 16 Apr 2002 18:16:08 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 16 Apr 2002 18:16:08 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA01478; Tue, 16 Apr 2002 11:16:02 -0700 (PDT) Message-ID: <3CBC6781.A92CF330@redhat.com> Date: Tue, 16 Apr 2002 11:16:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Michal Ludvig CC: Eli Zaretskii , gdb Subject: Re: Strange segfaults of gdb References: <3CB5B5F1.7010809@suse.cz> <9743-Fri12Apr2002120839+0300-eliz@is.elta.co.il> <3CB6C492.80108@suse.cz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00270.txt.bz2 Michal Ludvig wrote: > > Eli Zaretskii wrote: > >>It doesn't matter which program I run, what I want to print and if I > >>then want invoke 'run', 'continue' or even 'si'. It segfaults. Core file > >>doesn't give any reasonable informations. > > > > You mean, you cannot even tell from the core file where (inside what > > function) GDB crashes? That'd be very strange indeed--what could > > prevent you from getting att his information? Is the core file > > corrupt or something? > > I can see the same information as if I run gdb from gdb. Anyway I treat > them incorrect [see below]. > > > What if you run GDB under another GDB--can you see where does the > > subordinate GDB crash then? > > (gdb) p 1 > $1 = 1 > (gdb) r > Starting program: /root/mludvig/tst/xmmtest > > Program received signal SIGSEGV, Segmentation fault. > 0x2a95ae759c in wait4 () at soinit.c:76 > 76 } > (top-gdb) disassemble 0x2a95ae759c > Dump of assembler code for function wait4: > 0x2a95ae7590 : mov %rcx,%r10 > 0x2a95ae7593 : mov $0x3d,%rax > 0x2a95ae759a : syscall > 0x2a95ae759c : cmp $0xfffffffffffff001,%rax > 0x2a95ae75a2 : jae 0x2a95ae75a5 > 0x2a95ae75a4 : retq > 0x2a95ae75a5 : xor %rdx,%rdx > 0x2a95ae75a8 : sub %rax,%rdx > 0x2a95ae75ab : push %rdx > 0x2a95ae75ac : callq 0x2a95a6fa30 > 0x2a95ae75b1 : pop %rdx > 0x2a95ae75b2 : mov %rdx,(%rax) > 0x2a95ae75b5 : or $0xffffffffffffffff,%rax > 0x2a95ae75b9 : jmp 0x2a95ae75a4 > 0x2a95ae75bb : nop > 0x2a95ae75bc : nop > 0x2a95ae75bd : nop > 0x2a95ae75be : nop > 0x2a95ae75bf : nop > End of assembler dump. > > So it appears like the segfault happend on 'cmp ,' > instruction, which shouldn't be able to generate any exception at all. > So I don't trust this information. Maybe it took place during the syscall, and was deferred until return to user space? > Or do you have an idea how to interpret it? I don't say it's a bug in > the gdb - it may be in the kernel, glibc or gcc as well, but everything > else seems to work. Only gdb doesn't... > May this be a memory corruption problem on the gdb side (perhaps it > passes a wrong address to the syscall)? I'll try to use ElectricFence to > see what happens. > > Is there somewhere a tutorial on how to examine/compare core files > generated by gcore command? What should I look for? No -- but I was thinking you could just run "cmp" on them, and find out what memory had changed during the "print 1".