Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Oct 2024 11:50:50 +0300
From:      Konstantin Belousov <kib@freebsd.org>
To:        Paul Floyd <paulf2718@gmail.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Problems with FreeBSD-15.0-CURRENT-amd64-20241003
Message-ID:  <ZwZD6rP1eQ2ehllX@kib.kiev.ua>
In-Reply-To: <CALUVJ=AhS1NA_4JNEC-c2hMjBMHhNZh0VzLjdvCVDh5siDrriw@mail.gmail.com>
References:  <7bdb3c71-8a36-444e-8b1d-9c4f789fe638@gmail.com> <ZwYrWwd5XU_TRbEw@kib.kiev.ua> <CALUVJ=AhS1NA_4JNEC-c2hMjBMHhNZh0VzLjdvCVDh5siDrriw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 09, 2024 at 10:27:22AM +0200, Paul Floyd wrote:
> >
> > On Wed, 9 Oct 2024 at 09:08, Konstantin Belousov <kostikbel@gmail.com>
> > wrote:
> >
> On Wed, Oct 09, 2024 at 06:35:08AM +0000, Paul Floyd wrote:
> > > The biggest problem is with Helgrind. All apps now generate an extra
> > error
> > >
> > > ==68593== Thread #1: Exiting thread still holds 1 lock
> > > ==68593==    at 0x4BBB5DA: _exit (in /lib/libsys.so.7)
> > > ==68593==    by 0x49FC1C0: exit (in /lib/libc.so.7)
> > > ==68593==    by 0x491CA10: __libc_start1 (in /lib/libc.so.7)
> > > ==68593==    by 0x20182F: (below main) (crt1_s.S:83)
> >
> 
> 
> > This is intended, see 3f3ec4b99f79d32a0bf15495559ca9883bd751f2.
> >
> >
> Reply to list is better,
> 
> Ug. I need to test but I don't think that I can simply add a default
> suppression for this as that would also mask any leaked user locks.
> 
> I can probably check whether it's the main thread (I assume that this code
> doesn't run on subsidiary threads) and then only warn if there are 2 or
> more locks held. The next problem is that I don't see any way to tell
> whether I need to allow one lock or not. This is all userland so so
> __FreeBSD_version change. Also I don't see any public symbols. That just
> leaves me with configure time 'uname' checks.

No, this is not limited to the main thread.  Whatever thread called exit()
and won the race to get the lock, would keep it owned till the process
exit.

Perhaps you can check for the presence of the symbol exit@FBSD_1.0 in the
backtrace to determine the situation.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZwZD6rP1eQ2ehllX>