Re: cmake hanging

[Andrew Doran <ad%netbsd.org@localhost>]

On Wed, Jun 10, 2020 at 01:30:22AM +0200, Joerg Sonnenberger wrote:

> On Tue, Jun 09, 2020 at 11:22:27PM +0000, Andrew Doran wrote:
> > On Sat, Jun 06, 2020 at 09:25:55PM +0200, Joerg Sonnenberger wrote:
> > 
> > > On Sat, Jun 06, 2020 at 06:45:03PM +0100, Chavdar Ivanov wrote:
> > > > On Sat, 6 Jun 2020 at 18:43, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I got another cmake hang during pkg_rolling-replace today, while
> > > > > building misc/kdepimlibs4, trace as follows:
> > > > 
> > > > Just to mention that after I quit gdb and detached from the process it
> > > > continued and completed the build . . .
> > > 
> > > Right, that's the bug in the mutex wakeup handling.
> > 
> > Hmm.  From what I've seen I'm starting to suspect that it's a signal handler
> > screwing up a waiting thread underneath it, by playing with threads stuff.

I have made pthread_mutex and pthread_cond hopefully insensitive to that. 
If something is badly behaved and calls pthread_cond_broadcast() from a
signal handler for example it shouldn't cause any damage.
 
> I've been wondering if we actually want to have SA_RESTART behavior for
> _lwp_park.

It relies on EINTR being returned at the moment.  Consider for example if a
signal is taken, and during signal processing a wakeup is eaten by
_lwp_park() called by the dynamic linker for its locks.  On the way back out
the parked thread needs to restart and check if it has actually been awoken,
because it might never see a wakeup.

Andrew