From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-8438-listarch-gdb=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 20283 invoked by alias); 12 Apr 2002 12:05:48 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 20268 invoked from network); 12 Apr 2002 12:05:44 -0000
Received: from unknown (HELO mirapoint.inter.net.il) (192.114.186.20)
  by sources.redhat.com with SMTP; 12 Apr 2002 12:05:44 -0000
Received: from zaretsky (diup-217-24.inter.net.il [213.8.217.24])
	by mirapoint.inter.net.il (Mirapoint Messaging Server MOS 2.9.3.2)
	with ESMTP id AAZ27960;
	Fri, 12 Apr 2002 15:05:34 +0300 (IDT)
Date: Fri, 12 Apr 2002 05:05:00 -0000
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: mludvig@suse.cz
Message-Id: <4331-Fri12Apr2002150053+0300-eliz@is.elta.co.il>
CC: gdb@sources.redhat.com
In-reply-to: <3CB6C492.80108@suse.cz> (message from Michal Ludvig on Fri, 12
	Apr 2002 13:27:14 +0200)
Subject: Re: Strange segfaults of gdb
Reply-to: Eli Zaretskii <eliz@is.elta.co.il>
References: <3CB5B5F1.7010809@suse.cz> <9743-Fri12Apr2002120839+0300-eliz@is.elta.co.il> <3CB6C492.80108@suse.cz>
X-SW-Source: 2002-04/txt/msg00207.txt.bz2

> Date: Fri, 12 Apr 2002 13:27:14 +0200
> From: Michal Ludvig <mludvig@suse.cz>
> 
> > 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

It's more useful to type "bt" at this point.  Then you will know what
kind of code in GDB called wait4.

> Dump of assembler code for function wait4:
> 0x2a95ae7590 <wait4>:   mov    %rcx,%r10
> 0x2a95ae7593 <wait4+3>: mov    $0x3d,%rax
> 0x2a95ae759a <wait4+10>:        syscall
> 0x2a95ae759c <wait4+12>:        cmp    $0xfffffffffffff001,%rax
> 0x2a95ae75a2 <wait4+18>:        jae    0x2a95ae75a5 <wait4+21>
> 0x2a95ae75a4 <wait4+20>:        retq
> 0x2a95ae75a5 <wait4+21>:        xor    %rdx,%rdx
> 0x2a95ae75a8 <wait4+24>:        sub    %rax,%rdx
> 0x2a95ae75ab <wait4+27>:        push   %rdx
> 0x2a95ae75ac <wait4+28>:        callq  0x2a95a6fa30 <key+145504>
> 0x2a95ae75b1 <wait4+33>:        pop    %rdx
> 0x2a95ae75b2 <wait4+34>:        mov    %rdx,(%rax)
> 0x2a95ae75b5 <wait4+37>:        or     $0xffffffffffffffff,%rax
> 0x2a95ae75b9 <wait4+41>:        jmp    0x2a95ae75a4 <wait4+20>
> 0x2a95ae75bb <wait4+43>:        nop
> 0x2a95ae75bc <wait4+44>:        nop
> 0x2a95ae75bd <wait4+45>:        nop
> 0x2a95ae75be <wait4+46>:        nop
> 0x2a95ae75bf <wait4+47>:        nop
> End of assembler dump.
> 

> So it appears like the segfault happend on 'cmp <imm>,<reg>' 
> instruction, which shouldn't be able to generate any exception at all.

I suspect that what crashed is the syscall instruction before that:

> Dump of assembler code for function wait4:
> 0x2a95ae7590 <wait4>:   mov    %rcx,%r10
> 0x2a95ae7593 <wait4+3>: mov    $0x3d,%rax
> 0x2a95ae759a <wait4+10>:        syscall
> 0x2a95ae759c <wait4+12>:        cmp    $0xfffffffffffff001,%rax

It is also possible that the stack is somehow blown up, which would
explain why the first instruction after a syscall return crashes.