[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Test-lock hang (not 100% reproducible) on GNU/Linux
From: |
Pavel Raiskup |
Subject: |
Re: Test-lock hang (not 100% reproducible) on GNU/Linux |
Date: |
Fri, 06 Jan 2017 17:49:04 +0100 |
User-agent: |
KMail/5.3.3 (Linux/4.8.15-300.fc25.x86_64; KDE/5.27.0; x86_64; ; ) |
On Thursday, January 5, 2017 7:51:00 PM CET Bruno Haible wrote:
> Pavel Raiskup wrote:
> > Thanks. Minor report is that gl_thread_join() is not handled properly for
> > joined thread statuses.
> >
> > This leads to situation that Koji build system tries to gently terminate
> > the build first (after two days) ... which (sometimes?) leads to successful
> > 'test-lock' run in the end and the build succeeds too a bit later.
>
> I cannot explain why this happens and how to fix it. If pthread_join would
> report an error code, glthread_join would as well, and gl_thread_join would
> abort the process, and 'make check' would fail:
>
> # define glthread_join(THREAD, RETVALP) \
> (pthread_in_use () ? pthread_join (THREAD, RETVALP) : 0)
>
> #define gl_thread_join(THREAD, RETVAL) \
> do \
> { \
> if (glthread_join (THREAD, RETVAL)) \
> abort (); \
> } \
> while (0)
It looks like RETVALP shouldn't be NULL. Dunno whether the success is
matter of luck or whether it is guaranteed thing.
Pavel
Re: Test-lock hang (not 100% reproducible) on GNU/Linux, Bruno Haible, 2017/01/05
Re: Test-lock hang (not 100% reproducible) on GNU/Linux, Torvald Riegel, 2017/01/05
Re: C11 atomics, Bruno Haible, 2017/01/05
Re: read-write locks, Bruno Haible, 2017/01/05