Red Hat Bugzilla – Bug 161468
x86_64 gdb passes ERESTARTNOHAND to user process
Last modified: 2015-01-04 17:20:33 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 Description of problem: I'm chasing a problem on linux 2.6.11.11 x86_64 where when you attach gdb, select() returns ERESTARTNOHAND (errno 514) to the user process. The same problem occurs whether it is a 32bit or 64bit process being debugged. On i386, it seems as if the EIP is backed up 2 insn's to execute the 'jmp' insn that causes the system call to be restarted. On x86_64, the EIP is not backed up, the system call is not restarted, and the internal kernel errno is passed on to the user process. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.attach to a process with gdb, or stop the running process within gdb 2.call a function, eg 'call sleep(1)' 3.continue program execution Actual Results: select() returns -1 and errno is set to 514 (ERESTARTNOHAND) Expected Results: the select() call should be restarted. the internal linux errno should not be passed to the user process. Additional info: :::: calling a function on x86_64 :::: Program received signal SIGINT, Interrupt. 0xffffe405 in __kernel_vsyscall () 1: x/i $pc 0xffffe405 <__kernel_vsyscall+5>: mov $0x2b,%ecx (gdb) call doNothing() (gdb) x/i $pc 0xffffe405 <__kernel_vsyscall+5>: mov $0x2b,%ecx (gdb) x/8i 0xffffe400 0xffffe400 <__kernel_vsyscall>: push %ebp 0xffffe401 <__kernel_vsyscall+1>: mov %ecx,%ebp 0xffffe403 <__kernel_vsyscall+3>: syscall 0xffffe405 <__kernel_vsyscall+5>: mov $0x2b,%ecx 0xffffe40a <__kernel_vsyscall+10>: movl %ecx,%ss 0xffffe40c <__kernel_vsyscall+12>: mov %ebp,%ecx 0xffffe40e <__kernel_vsyscall+14>: pop %ebp 0xffffe40f <__kernel_vsyscall+15>: ret (gdb) stepi 0xffffe40a in __kernel_vsyscall () 1: x/i $pc 0xffffe40a <__kernel_vsyscall+10>: movl %ecx,%ss (gdb) stepi 0xffffe40e in __kernel_vsyscall () 1: x/i $pc 0xffffe40e <__kernel_vsyscall+14>: pop %ebp :::: calling a function on i386 :::: Program received signal SIGINT, Interrupt. 0xffffe410 in __kernel_vsyscall () 1: x/i $pc 0xffffe410 <__kernel_vsyscall+16>: pop %ebp (gdb) x/8i 0xffffe400 0xffffe400 <__kernel_vsyscall>: push %ecx 0xffffe401 <__kernel_vsyscall+1>: push %edx 0xffffe402 <__kernel_vsyscall+2>: push %ebp 0xffffe403 <__kernel_vsyscall+3>: mov %esp,%ebp 0xffffe405 <__kernel_vsyscall+5>: sysenter 0xffffe407 <__kernel_vsyscall+7>: nop 0xffffe408 <__kernel_vsyscall+8>: nop 0xffffe409 <__kernel_vsyscall+9>: nop 0xffffe40a <__kernel_vsyscall+10>: nop 0xffffe40b <__kernel_vsyscall+11>: nop 0xffffe40c <__kernel_vsyscall+12>: nop 0xffffe40d <__kernel_vsyscall+13>: nop 0xffffe40e <__kernel_vsyscall+14>: jmp 0xffffe403 <__kernel_vsyscall+3> 0xffffe410 <__kernel_vsyscall+16>: pop %ebp 0xffffe411 <__kernel_vsyscall+17>: pop %edx 0xffffe412 <__kernel_vsyscall+18>: pop %ecx 0xffffe413 <__kernel_vsyscall+19>: ret (gdb) call doNothing() (gdb) stepi 0xffffe403 in __kernel_vsyscall () 1: x/i $pc 0xffffe403 <__kernel_vsyscall+3>: mov %esp,%ebp (gdb) c Continuing. Program received signal SIGINT, Interrupt. 0xffffe410 in __kernel_vsyscall () 1: x/i $pc 0xffffe410 <__kernel_vsyscall+16>: pop %ebp (gdb) call doNothing() (gdb) x/i $pc 0xffffe410 <__kernel_vsyscall+16>: pop %ebp (gdb) stepi 0xffffe403 in __kernel_vsyscall () 1: x/i $pc 0xffffe403 <__kernel_vsyscall+3>: mov %esp,%ebp
Created attachment 115879 [details] sample source gtest.c small test program which reproduces problem
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
I'm having trouble with getting kernel-2.6.12-1.1372_FC3 to boot. I tried rebuilding the kernel, but I'm having troubles with that too. Unknown symbol when loading modules. It will take me a while to figure out how to make it work.
That sounds like the problem in bug 163407. Make sure you install the latest mkinitrd update, then, remove the latest kernel-smp package, and reinstall it. This will recreate a working initrd.
I've tested this with kernel-2.6.12-1.1372_FC3, and the problem still occurs.
This is a mass-update to all currently open Fedora Core 3 kernel bugs. Fedora Core 3 support has transitioned to the Fedora Legacy project. Due to the limited resources of this project, typically only updates for new security issues are released. As this bug isn't security related, it has been migrated to a Fedora Core 4 bug. Please upgrade to this newer release, and test if this bug is still present there. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. Thank you.
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
Closing per previous comment.