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 -----------------------------------------------------------------