On Jun 06 2017, "Dmitry V. Levin" wrote:
> Why clock_nanosleep is restarted after being interrupted by a signal
> handler? What kind of kernel is behaving this way?
Indeed, this was a kernel bug.
Thanks, Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 9
On Mon, Jun 05, 2017 at 05:34:16PM +0200, Andreas Schwab wrote:
> A lot of tests fail because clock_nanosleep fails:
>
> $ ../strace -e clock_nanosleep ./clock_nanosleep >/dev/null
> clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=789985}, NULL) = 0
> clock_nanosleep(CLOCK_REALTIME, 0, NULL,
On Mon, Jun 05, 2017 at 05:34:16PM +0200, Andreas Schwab wrote:
> A lot of tests fail because clock_nanosleep fails:
>
> $ ../strace -e clock_nanosleep ./clock_nanosleep >/dev/null
> clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=789985}, NULL) = 0
> clock_nanosleep(CLOCK_REALTIME, 0, NULL,
A lot of tests fail because clock_nanosleep fails:
$ ../strace -e clock_nanosleep ./clock_nanosleep >/dev/null
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=789985}, NULL) = 0
clock_nanosleep(CLOCK_REALTIME, 0, NULL, 0xefca3994) = -1 EFAULT (Bad address)
clock_nanosleep(CLOCK_REALTIME, 0,