https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
--- Comment #8 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Sam James from comment #4)
Thanks.
> (In reply to David Malcolm from comment #2)
> > What does printing *wrapper in the debugger look like?
> >
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff25f8007 in gcc::jit::wrapper_finalizer (ptr=0x7fffdc491e70) at
> /usr/src/debug/sys-devel/gcc-15.0.9999/gcc-15.0.9999/gcc/jit/jit-playback.cc:
> 2094
> 2094 wrapper->finalizer ();
> (gdb) p wrapper
> $1 = (gcc::jit::playback::wrapper *) 0x7fffdc491e70
> (gdb) p *wrapper
> $2 = {_vptr.wrapper = 0x0}
wrapper_finalizer is a callback passed to ggc_internal_cleared_alloc; it's
being called with NULL.
Looking at finalizer::call I see:
void call () const { m_function (m_addr); }
so presumably we somehow have a finalizer with NULL m_addr, but I don't see how
that can happen: they're only created by add_finalizer with "result", and
result seems to need to be non-NULL (unless I'm missing something).
Unfortunately I still haven't been able to reproduce this locally.
Looking at
https://www.gnu.org/software/emacs/manual/html_node/elisp/Native_002dCompilation-Variables.html
there are a few options, but what would be really helpful is an option to call
gcc_jit_context_set_bool_option (ctxt, GCC_JIT_BOOL_OPTION_SELFCHECK_GC);
on the underlying gcc_jit_context (or I suppose you could hack up your emacs
build to do this). It will *really* slow down libgccjit's code generation, but
ought to make the bug reproduce more reliably (and thus hopefully allow
minimization from the Lisp side).
