Date: Thu, 10 Oct 2024 14:16:49 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Paul Floyd <paulf2718@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Problems with FreeBSD-15.0-CURRENT-amd64-20241003 Message-ID: <Zwe3oX7HJ-jtsyP_@kib.kiev.ua> In-Reply-To: <62745a68-9ed7-4f6f-bd6f-0ba3e10629c3@gmail.com> References: <7bdb3c71-8a36-444e-8b1d-9c4f789fe638@gmail.com> <ZwYrWwd5XU_TRbEw@kib.kiev.ua> <CALUVJ=AhS1NA_4JNEC-c2hMjBMHhNZh0VzLjdvCVDh5siDrriw@mail.gmail.com> <ZwZD6rP1eQ2ehllX@kib.kiev.ua> <62745a68-9ed7-4f6f-bd6f-0ba3e10629c3@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 09, 2024 at 07:34:31PM +0000, Paul Floyd wrote: > > > On 09-10-24 08:50, Konstantin Belousov wrote: > > > Perhaps you can check for the presence of the symbol exit@FBSD_1.0 in the > > backtrace to determine the situation. > > We don't read .gnu.version and the version number hasn't changed as far as I > can see. > > I can check osreldate to get an idea of the version. > > However this looks like it is going to be a lot more difficult. I need to be > able to tell apart abnormal termination (where no locks are to be expected) > and normal termination (one lock expected). > > If it's not possible/too difficult to work out how mnay locks should be > allowed on exit another option will be to try to fiddle around with what > happens during a call to exit(). That would mean something like ignoring the > lock count when called from exit(). > > And the last resort will be to just turn this check off. If you can determine not just the number of taken locks, but also the specific locks that were taken, perhaps you can check that this is the libc exit lock?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Zwe3oX7HJ-jtsyP_>