https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[15 regression] Segfault in |[15 regression] Segfault in
|gcc/jit/jit-playback.cc |libgccjit garbage
|when compiling GNU Emacs |collection when compiling
|with Native Compilation |GNU Emacs with Native
| |Compilation
--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Dario Gjorgjevski from comment #0)
> GCC commit ff889b359
> GNU Emacs commit 9ed82c2
>
> When I attempt to compile GNU Emacs with `Native Compilation
> <https://www.gnu.org/software/emacs/manual/html_node/elisp/Native-
> Compilation.html>_, there is a segfault in gcc/jit/jit-playback.cc.
>
> (lldb) run
> Process 96017 launched: '/Volumes/src/emacs/src/bootstrap-emacs' (x86_64)
> Process 96017 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=1, address=0x0)
> frame #0: 0x0000000104ce7553
> libgccjit.0.dylib`gcc::jit::wrapper_finalizer(ptr=0x0000000104777f50) at
> jit-playback.cc:1900:22
> 1897 wrapper_finalizer (void *ptr)
> 1898 {
> 1899 playback::wrapper *wrapper = reinterpret_cast
> <playback::wrapper
> *> (ptr);
> -> 1900 wrapper->finalizer ();
> 1901 }
> 1902
> 1903 /* gcc::jit::playback::wrapper subclasses are GC-managed:
> Target 0: (bootstrap-emacs) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=1, address=0x0)
> * frame #0: 0x0000000104ce7553
> libgccjit.0.dylib`gcc::jit::wrapper_finalizer(ptr=0x0000000104777f50) at
> jit-playback.cc:1900:22
> frame #1: 0x0000000105acc827 libgccjit.0.dylib`ggc_collect(ggc_collect)
> [inlined] finalizer::call(this=0x00007fca639372f8) const at
> ggc-page.cc:333:35
> frame #2: 0x0000000105acc820 libgccjit.0.dylib`ggc_collect(ggc_collect)
> at ggc-page.cc:1932:15
> frame #3: 0x0000000105acc7c2
> libgccjit.0.dylib`ggc_collect(mode=<unavailable>) at ggc-page.cc:2232:25
> frame #4: 0x0000000105b8f767
> libgccjit.0.dylib`cgraph_node::finalize_function(decl=0x0000000100c56c00,
> no_collect=<unavailable>) at cgraphunit.cc:506:17
> frame #5: 0x0000000104ce8f0e
> libgccjit.0.dylib`gcc::jit::playback::function::
> postprocess(this=0x0000000100c25d70) at jit-playback.cc:2111:38
> frame #6: 0x0000000104cea49a
> libgccjit.0.dylib`gcc::jit::playback::context::
> replay(this=0x00007ff7bfef6c30) at jit-playback.cc:3455:22
> frame #7: 0x0000000107adb9e0 libgccjit.0.dylib`global_options_set + 6400
> frame #8: 0x00000001078ecfa0
> libgccjit.0.dylib`hard_frame_pointer_adjustment + 24
> frame #9: 0x0000000107adb9e0 libgccjit.0.dylib`global_options_set + 6400
>
> The issue does not happen with the releases/gcc-14 branch -- commit
> be06962b3 in particular.
>
> Any hints how to debug this further?
What does printing *wrapper in the debugger look like?
FWIW from the libgccjit side, there's gcc_jit_context_dump_reproducer_to_file
https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#c.gcc_jit_context_dump_reproducer_to_file
which in theory ought to give you a standalone C reproducer (without needing
emacs), but I don't know if that's exposed in an easy way from the emacs
native-compilation code that's invoking libgccjit.
The backtrace shows this is happening during GCC's garbage collection, so I
wonder if this is a dormant bug in memory management that your use case is
happening to trigger. You could try:
gcc_jit_context_set_bool_option (GCC_JIT_BOOL_OPTION_SELFCHECK_GC);
as per
https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#c.gcc_jit_context_set_bool_option.GCC_JIT_BOOL_OPTION_SELFCHECK_GC
to see if it triggers the bug earlier (or perhaps on gcc-14) but note that that
option will make libgccjit *really* slow at compiling.
