Ahh! This triggers the memory. Yes, the signal mask gets completely
hosed during a sigprocmask() call. (sigprocmask() is called by
sigsetjmp/siglongjmp). The cause is as follows:
There are a set of defines in /usr/include/signal.h for SIG_BLOCK,
SIG_UNBLOCK, and SIG_SETMASK. The OS defines these as having
values 0, 1, and 2.
However, the C library was compiled with a different header file
that defines these same constants as having values 1, 2, and 3.
Thus, when the sigsetjmp/siglongjmp think that they are doing a
SIG_SETMASK, they are actually doing a SIG_UNBLOCK, or some
such (I forget exactly which value is being mistaken for which,
but you get the idea).
SR #5003-301150 describes the symptoms, but apparently did not
find the root cause. I know I opened another SR about this
earlier this year, but can't find the SR (I think probably
because it's on the Roseville system and not our Cupertino
system). Walter Murray provided a fix to me personally, and
it was going to get rolled into the next submittal of the C
library. So I know the fix exists; perhaps whoever you're
working with at the RC can have better luck finding a patch
ID for it.
Mike
Mark Bixby ([log in to unmask]) wrote:
: Oh what a fun journey this EINTR problem is taking me on. ;-)
: The HPRC and I can't explain the deferred EINTR yet, but I think I've discovered
: that sigsetjmp() and siglongjmp() aren't behaving properly.
: It looks like when you use siglongjmp() to exit out of a signal catching
: interrupt handler function, the process signal mask isn't being restored to
: the value that was supposedly saved earlier by sigsetjmp().
: I've confirmed this using :DEBUG to examine pibx_type.px_signals[SIGALRM]. The
: initial state is properly unblocked with no pending signals. After the first
: SIGALRM is sent and received and the interrupt handler function has exited via
: siglongjmp(), the state is now incorrectly blocked with no pending signals.
: If a subsequent SIGALRM is sent, the interrupt handler never executes, and
: the state is now blocked with one pending signal. This definitely seems broken
: to me.
: Have any of you other POSIX people seen this problem? Or have you seen apps
: where this stuff worked properly? Let me know. Thanks!
: --
: Mark Bixby E-mail: [log in to unmask]
: Coast Community College Dist. Web: http://www.cccd.edu/~markb/
: District Information Services 1370 Adams Ave, Costa Mesa, CA, USA 92626-5429
: Technical Support Voice: +1 714 438-4647
: "You can tune a file system, but you can't tune a fish." - tunefs(1M)
--
-----------------------------------------------------------------
Mike Yawn
Hewlett-Packard email [log in to unmask]
Commercial Systems Division Voice (408) 447-4367
19447 Pruneridge Ave M/S 47UA Fax (408) 447-4441
Cupertino, CA 95014
-----------------------------------------------------------------
|
