Re: Strange segfaults of gdb

["Eli Zaretskii" <eliz@is.elta.co.il>]

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