Re: BUG #16696: Backend crash in llvmjit - Mailing list pgsql-bugs

From Dmitry Marakasov
Subject Re: BUG #16696: Backend crash in llvmjit
Date
Msg-id 20201116004529.GC5149@hades.panopticon
Whole thread Raw
In response to Re: BUG #16696: Backend crash in llvmjit  (Andres Freund <andres@anarazel.de>)
Responses Re: BUG #16696: Backend crash in llvmjit
List pgsql-bugs
* Andres Freund (andres@anarazel.de) wrote:

> > The problem happens when boolin() function is inlined by LLVM.
> > The named function calls isspace() internally, which on FreeBSD is
> > locale-specific and involves caching some locale parameters in
> > thread-local variable defined as
> > 
> > extern _Thread_local const _RuneLocale *_ThreadRuneLocale;
> > 
> > The execution crashes on trying to access the named thread-local varible,
> > probably because something related to TLS is not set up properly in/for
> > LLVM.
> > 
> > I've confirmed this hypothesis by disabling isspace() calls in boolin()
> > which has also fixed the problem.
> 
> Nice digging. I suspect your approach of disabling inlining for TLS
> might be the most reasonable one for now.
> 
> Any chance you're interested in extending your patch with a testcase
> that crashes reliably without it? Best on multiple platforms, including
> linux? Easiest way would probably be to add a function referencing a
> thread local variable in regress.c and set jit_above_cost = 0,
> jit_inline_above_cost=0 for a query using that function.

Can try. Here's what I could come with so far:

https://github.com/postgres/postgres/compare/master...AMDmi3:llvm-jit-regress.patch

Unfortunately it doesn't crash with the dedicated function, likely
because there's no llvm bitcode generation performed for regress.c.
It does however reliably crash on

SELECT (jsonb_array_elements('[true]'::jsonb)->>0)::boolean;
or
SELECT (case when random() >= 0.5 then 'true' else 'false' end)::boolean;

but it would likely not reproduce on Linux due to different isspace
implementation. Notably, it does not crash on simple 'true'::boolean,
I guess because it may be evaluated at compile time.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru  ..:              https://github.com/AMDmi3




pgsql-bugs by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Unnecessary FOR UPDATE lock instead of possible FOR NO KEY UPDATE lock in an UPSERT statement
Next
From: PG Bug reporting form
Date:
Subject: BUG #16721: ERROR: could not load library "/usr/pgsql-11/lib/rtpostgis-2.5.so": /usr/gdal32/lib/libgdal.so.28: