https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219228
Bug ID: 219228
Summary: EINTR on thread with full signal mask.
Product: Base System
Version: 10.3-STABLE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs@FreeBSD.org
Reporter: parakl...@darkreality.org
Created attachment 182523
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=182523&action=edit
Test program: compile with `cc -lthr main.c`; Send '^t^t^t^c' to observe
problem.
I don't know if this is a bug or within the bounds of undefined behaviour, but
I certainly found it surprising.
Essentially I have a thread with all possible signals masked and I expect that
it should never return the error of EINTR because it will never catch any
signals. It seems however that if there are signals queued (not just pending)
then when the signals are dequeued then the last started thread is interrupted
even if it doesn't handle the signal.
In the attached sample program if SIGINFO is sent three times, the first is
handled (but then the handler blocks at `pause()`), the second is pending, and
the third is queued. When then sending a SIGINT the handler unblocks, returns,
then receives the pending SIGINFO and blocks again, but then the worker thread
is woken and interrupted with EINTR.
The test program prints '*' for every iteration of the worker thread (1 per
second), 'HND' when the signal handler is entered, and 'WRK: Interrupted system
call' when the worker thread is interrupted.
If SIGINFO is only sent two times then the EINTR in the worker thread never
occurs. If it is sent more than three times then an EINTR is received every
time a queued signal is moved from the queue to pending.
I don't understand this area of the kernel code enough to know where the
problem is, but I don't believe a masked signal should cause an EINTR. If it
is necessary to interrupt a thread for some reason when the signal is masked
everywhere is there any chance that this could be forced to the main thread
rather than to the last started. At least the main thread is identifiable.
With the current behaviour I cannot even have a single sacrificial thread to
handle these because whenever a new thread is started it becomes the target of
the EINTR.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
