Date: Fri, 12 May 2017 00:44:16 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219228] EINTR on thread with full signal mask. Message-ID: <bug-219228-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219228 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: parakleta@darkreality.org Created attachment 182523 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D182523&action= =3Dedit 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 t= hat 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 pendi= ng) then when the signals are dequeued then the last started thread is interrup= ted 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, retu= rns, then receives the pending SIGINFO and blocks again, but then the worker thr= ead 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 sy= stem 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.= =20 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219228-8>