Re: Strange segfaults of gdb

Michael Snyder
2002-04-16T18:16:12Z

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

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