On Thu, Aug 05, 2021 at 02:58:03PM +0100, Daniel P. Berrangé wrote:
On Thu, Aug 05, 2021 at 03:33:57PM +0200, Tim Wiederhake wrote:
> On Thu, 2021-08-05 at 14:24 +0100, Daniel P. Berrangé wrote:
> > On Thu, Aug 05, 2021 at 03:08:50PM +0200, Tim Wiederhake wrote:
> > > `pthread_mutex_destroy`, `pthread_mutex_lock` and
> > > `pthread_mutex_unlock`
> > > return an error code that is currently ignored.
> > >
> > > Add debug information if one of these operations failed, e.g. when
> > > there
> > > is an attempt to destroy a still locked mutex or unlock and already
> > > unlocked mutex.
> >
> > We ignore the errors because in practice we found impls don't return
> > any error code when using PTHREAD_MUTEX_NORMAL - it would require use
> > of PTHREAD_MUTEX_ERRORCHECK.
> >
> > Did you actually see errors returned for real ?
>
> Yes. Please note that I apprently copy-pasted the wrong link in the
> cover letter. The pipeline for this series is correct
> (
https://gitlab.com/twiederh/libvirt/-/pipelines/348505233), the
> pipeline for only patches 5, 6, 7 that demonstrate the non-zero return
> values of pthread_mutex_{lock,unlock,destroy} is here:
>
>
https://gitlab.com/twiederh/libvirt/-/pipelines/348505770
All that's showing is
(killed by signal 6 SIGABRT)
where's the VIR_WARN output that ought to have ended up on stderr
from the failed test before aborting ?
Ok, so the VIR_WARN output is getting squelched by the tests
somewhere, as its missing when i run locally too.
If I add a test that does
virMutex m;
ignore_value(virMutexInit(&m));
virMutexUnlock(&m);
then I get no warnings with this patch, nor abort with the next
patch.
It only triggers with PTHREAD_MUTEX_ERRORCHECK
The pthread_mutex_destroy call is the only one that I see
returning errors with PTHREAD_MUTEX_NORMAL. So I don't think
there's benefit to adding the code to lock/unlock paths.
Regards,
Daniel
--
|: