Red Hat Bugzilla – Bug 145338
attach or detach during nanosleep in 32 bit process returns EINVAL instead of EINTR
Last modified: 2013-03-06 00:58:02 EST
Description of problem:
(Component is just a guess)
Executing nanosleep from a 32-bit returns wrong value in errno when interrupted
by a signal (EINVAL instead of EINTR). For quick reference here is man page
In case of an error or exception, the nanosleep system call returns -1 instead
of 0 and sets errno to one of the following values:
The pause has been interrupted by a non-blocked signal that was delivered to
the process. The remaining sleep time has been written into *rem so that the
process can easily call nanosleep again and continue with the pause.
The value in the tv_nsec field was not in the range 0 to 999 999 999 or tv_sec
Version-Release number of selected component (if applicable):
Run repro.sh from attached archive.
errno is EINVAL
errno should be EINTR
Created attachment 109867 [details]
repro.c, Makefile and shell script to demonstrate correct 64-bit and errant 32-bit behavior
*** Bug 145337 has been marked as a duplicate of this bug. ***
This is a kernel thing, glibc's nanosleep just issues the nanosleep syscall.
Earlier description is misleading. The crux of the problem is that
our debugging methodology revolves around spinning in a loop that
pauses briefly in nanosleep so long as a given "spinfile" exists.
This allows us to attach a debugger before a given context is lost.
The act of attach to a 32 bit process in one of these spin loops
exhibits a bug. It appears that some aspect of the attach performs an
madvise with a bad 3rd argument (int advice). This seems to leave an
corrupted errno containing EINVAL instead of the expected EINTR:
madvise(0xffffda10, 4294957576, 0x6b1ff4) = -1 EINVAL (Invalid argument)
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life.
Please See https://access.redhat.com/support/policy/updates/errata/
If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.