Subject: bug#76327: 29.4; random segfaults after switch to tree-sitter

From: Pip Cet <[email-masked]>
Date: Wed, 19 Feb 2025 20:14:53 +0000

"Evgeniy Dushistov via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <[email-masked]> writes:

> On Wed, Feb 19, 2025 at 12:36:37PM +0000, Pip Cet wrote:
>> Please use "bt full", not "bt", and please keep the sessions alive in
>> gdb.
>>
>
> I ran it, waiting to crash again.
>
>> Also, please reproduce your precise CFLAGS and compiler version, there's
>> likely to be a problem there.
>>
>
> As I said earlier I used default compiler from Arch Linux distro:
> gcc (GCC) 14.2.1 20250207, I used default PKGBUILD from this distro for emacs package,

I tried building Emacs using makepkg and the archlinux docker image.  No
success so far: I finally managed to get a binory, but no crash so far.

> Appropriate part of my /etc/makepkg.conf, makepkg utility takes all flags from this file:
>
> CARCH="x86_64"
> CHOST="x86_64-pc-linux-gnu"
>
> CFLAGS="-march=nehalem -mtune=znver1 -O2 -pipe -fno-plt -fexceptions \
>         -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security \
>         -fstack-clash-protection -fcf-protection \
>         -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fno-optimize-sibling-calls"
> CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"
> LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now \
>          -Wl,-z,pack-relative-relocs"
> LTOFLAGS="-flto=auto"
> MAKEFLAGS="-j33"
> DEBUG_CFLAGS="-g"
> DEBUG_CXXFLAGS="$DEBUG_CFLAGS"
> DEBUG_RUSTFLAGS="-C debuginfo=2"
>
>
> I tried patched version of emacs (with modified flush_stack_call_func) with
> "-fno-optimize-sibling-calls" and without this flag.
> Both crashed.

Hmm.  And those crashes still aren't reproducible, and quite rare?  They
all look different, but they all look like GC hapened while unwinding
through the specpdl or otherwise calling longjmp.  And you say they
happen with Emacs-30, too?

I'm a bit confused that some builds mention LTO flags and some don't...

>> Please disassemble this function by running
>>
>> disass flush_stack_call_func
>>
>
> It is completely gone after inlining:
> (gdb) disassemble flush_stack_call_func
> No symbol "flush_stack_call_func" in current context.
> (gdb) disassemble flush_stack_call_func1
> Dump of assembler code for function flush_stack_call_func1:
>    0x000000000021d870 <+0>:	endbr64
>    0x000000000021d874 <+4>:	mov    0x5d2955(%rip),%rdx        # 0x7f01d0 <current_thread>
>    0x000000000021d87b <+11>:	push   %rbp
>    0x000000000021d87c <+12>:	mov    %rdi,%rax
>    0x000000000021d87f <+15>:	mov    %rsi,%rdi
>    0x000000000021d882 <+18>:	mov    %rsp,%rbp
>    0x000000000021d885 <+21>:	mov    %rbp,0x50(%rdx)
>    0x000000000021d889 <+25>:	call   *%rax
>    0x000000000021d88b <+27>:	pop    %rbp
>    0x000000000021d88c <+28>:	ret
> End of assembler dump.

Try disassembling mark_threads, though I expect that to be okay now, to
be honest.  Something else must be the problem.

Pip