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 description: ==== 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: EINTR 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. EINVAL The value in the tv_nsec field was not in the range 0 to 999 999 999 or tv_sec was negative. Version-Release number of selected component (if applicable): How reproducible: Run repro.sh from attached archive. Actual results: errno is EINVAL Expected results: errno should be EINTR Additional info:
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.