IceUtil/CtrlCHandler.cpp

[vukicevic]

In CtrlCHandler.cpp, line 134, the assert is triggered when an application that's using the CtrlCHandler (via IceUtil::Application) is run under gdb, terminating the application and making debugging difficult. According to the man page for sigwait, it's never supposed to return an error. However, it's returning EINTR in this instance; adding a "if (rc == EINTR) continue;" before the assert seems to fix the problem.

This is with Ice 1.1.0, stock Red Hat 9 install with glibc-2.3.2-27.9 and kernel-2.4.20-8. Is this fix correct? Or am I missing something?

[bernard]

Hi Vlad,

sigwait() is supposed to return 0 (success) or EINVAL (set contains an invalid signal handler -- impossible with Ice CtrCHandler). But it looks like on some OSs it can also return EINTR: the wait was interrupted by an unblocked caught signal according to the Solaris 9 man page.

So yes, your fix is correct. I'll investigate this further and include a fix in the next patch.

Thanks,
Bernard

[bernard]

From the Single UNIX Specification Version 3 rationale:
http://www.opengroup.org/onlinepubs/...ag_03_02_03_02

Disallowing Return of the [EINTR] Error Code
Many blocking interfaces defined by IEEE Std 1003.1-2001 may return [EINTR] if interrupted during their execution by a signal handler. Blocking interfaces introduced under the Threads option do not have this property. Instead, they require that the interface appear to be atomic with respect to interruption. In particular, clients of blocking interfaces need not handle any possible [EINTR] return as a special case since it will never occur. If it is necessary to restart operations or complete incomplete operations following the execution of a signal handler, this is handled by the implementation, rather than by the application.

Requiring applications to handle [EINTR] errors on blocking interfaces has been shown to be a frequent source of often unreproducible bugs, and it adds no compelling value to the available functionality. Thus, blocking interfaces introduced for use by multi-threaded programs do not use this paradigm. In particular, in none of the functions flockfile(), pthread_cond_timedwait(), pthread_cond_wait(), pthread_join(), pthread_mutex_lock(), and sigwait() did providing [EINTR] returns add value, or even particularly make sense. Thus, these functions do not provide for an [EINTR] return, even when interrupted by a signal handler. The same arguments can be applied to sem_wait(), sem_trywait(), sigwaitinfo(), and sigtimedwait(), but implementations are permitted to return [EINTR] error codes for these functions for compatibility with earlier versions of IEEE Std 1003.1. Applications cannot rely on calls to these functions returning [EINTR] error codes when signals are delivered to the calling thread, but they should allow for the possibility.


It's surprising that RH9 (and NPTL) does not implement it. Probably a bug!

Cheers,
Bernard

[vukicevic]

Heh, I'm not surprised that there's a bug I'll see if I can find any information regarding this and NPTL. Thanks for looking into the issue so quickly!