Re: Strange segfaults of gdb

[Michal Ludvig <mludvig@suse.cz>]

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 <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.
So I don't trust this information.
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?

It's somehow difficult to debug a broken debugger using a broken 
debugger :-((

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* +420 2 9654 5373   * http://www.suse.cz