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
iterations.
> 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
tomorrow.
Thanks again,
Corinna
--
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