Unexpected EINVAL from pthread_join

Corinna Vinschen corinna-cygwin@cygwin.com
Tue Feb 24 23:27:00 GMT 2015

Hi Lasse,

On Feb 24 20:37, Lasse Collin wrote:
> On 2015-02-24 Corinna Vinschen wrote:
> > On Feb 24 15:54, Lasse Collin wrote:
> > > Many other pthread functions are similar in sense that they must
> > > never return EINTR. A bug similar to the one in pthread::join exist
> > > in pthread_mutex::lock. If SA_RESTART isn't used, signals can make
> > > multiple threads get a lock on the same mutex at the same time. A
> > > test program is attached. Adding cw_sig_restart to the cygwait call
> > > in pthread_mutex::lock fixes this.
> > 
> > Can you collect the info which functions are affected so that lazy me
> > just has to apply the cw_sig_restart patches in bulk?
> I grepped for cygwait uses earlier but I don't understand the code well
> enough to be sure about anything. The following is pretty much
> guessing, but hopefully there's something useful still.
> These look the most suspicious to me, possibly needing cw_sig_restart:
>     thread.h          fast_mutex::lock
>     fhandler_tape.cc  fhandler_dev_tape::_lock
> When looking for things needing cw_sig_restart, I started to wonder if
> cw_sig_eintr is used properly in all cases. Often the caller of
> cygwait + cw_sig_eintr will also conditionally call
> _my_tls.call_signal_handler, but the following functions don't. The
> comment in handle_sigsuspend makes me think that this may be a false
> alarm but I mention these just in case.
>     exceptions.cc     handle_sigsuspend
>     posix_ipc.cc      ipc_mutex_lock
>     signal.cc         clock_nanosleep
>     signal.cc         sigwaitinfo
>     thread.cc         pthread_cond::wait
>     thread.cc         semaphore::_timedwait
>     thread.cc         semaphore::_wait

The signal code has gone through a couple of iterations so there's a
chance that some places do useless stuff; detritus from former

> In the following functions the situation is kind of reversed. Those
> functions call _my_tls.call_signal_handler even though cw_sig_eintr
> wasn't specified. cygwait will already have called the signal handler
> since cw_sig has been specified via cygwait(DWORD). So I guess in these
> functions the signal handler might get called twice.
>     fhandler_dsp.cc   fhandler_dev_dsp::Audio_out::waitforspace
>     fhandler_dsp.cc   fhandler_dev_dsp::Audio_in::waitfordata

Cool, thanks for looking so closely.  I wasn't expecting that, rather
just a look through the pthread functions but this is very helpful.
I'll check these code snippets in the next couple of days, maybe even

Thanks again,

Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20150224/5efd4bb2/attachment.sig>

More information about the Cygwin mailing list