Bug 161468 - x86_64 gdb passes ERESTARTNOHAND to user process
x86_64 gdb passes ERESTARTNOHAND to user process
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-23 12:18 EDT by Rich Coe
Modified: 2015-01-04 17:20 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-04 21:15:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sample source gtest.c (1.35 KB, application/octet-stream)
2005-06-23 12:25 EDT, Rich Coe
no flags Details

  None (edit)
Description Rich Coe 2005-06-23 12:18:54 EDT
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
Comment 1 Rich Coe 2005-06-23 12:25:25 EDT
Created attachment 115879 [details]
sample source gtest.c

small test program which reproduces problem
Comment 2 Dave Jones 2005-07-15 13:56:15 EDT
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.
Comment 3 Rich Coe 2005-07-21 11:50:49 EDT
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.
Comment 4 Dave Jones 2005-08-03 21:22:10 EDT
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.

Comment 5 Rich Coe 2005-08-08 13:41:35 EDT
I've tested this with kernel-2.6.12-1.1372_FC3, and the problem still occurs.
Comment 6 Dave Jones 2006-01-16 17:21:58 EST
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.
Comment 7 Dave Jones 2006-02-03 00:26:25 EST
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.
Comment 8 John Thacker 2006-05-04 21:15:12 EDT
Closing per previous comment.

Note You need to log in before you can comment on or make changes to this bug.