tfork() test hanging in socket_wrapper lock
abartlet at samba.org
Mon Nov 26 21:52:17 UTC 2018
On Tue, 2018-11-20 at 16:26 +0100, Ralph Böhme via samba-technical
> On Mon, Nov 19, 2018 at 07:12:17PM +0100, Andreas Schneider via samba-technical wrote:
> > On Monday, 19 November 2018 19:01:18 CET Andrew Bartlett wrote:
> > > On Mon, 2018-11-19 at 11:54 +0100, Andreas Schneider wrote:
> > > > On Monday, 19 November 2018 03:59:35 CET Andrew Bartlett wrote:
> > > > > Today on sn-devel my autobuild hung running the tfork test:
> > > > >
> > > > > It appears to be waiting forever for a mutex lock.
> > > >
> > > > Anoop and myself tried to reproduce it, but we couldn't. However helgrind
> > > > reports several errors in tfork itself.
> > >
> > > I should have mentioned, I've left them stuck in case they can be
> > > debugged.
> > I think Ralph already nailed it. It is an issue with SIGCHLD handling in
> > tfork.
> in fact it's not. :) Sorry for the red herring, but it took some time to swap
> the tfork details back into main memory.
> Taking a closer look at the data races reported by helgrind, I came to the
> conclusion that they are all false positives.
> The reported data races are in code that is globally serialized by
> tfork_acquire_sighandling() and tfork_release_sighandling(), ensuring there's
> always only one writer to the reported objects and all read accesses are
> sequenced after the write because there are a bunch of syscalls in between which
> serve as implicit memory barrier.
> I've added valgrind annotations to tfork.c to suppress the more subtle false
> positives. A few other false positives can't really be marked in the code, I've
> therefor added suppressions files for helgrind and dbd.
> metze, can you please take a close look at the attached (WIPish) patchset?
Are we any closer to getting this in, given we discovered this because
of stuck autobuilds?
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT
More information about the samba-technical