GNU bug report logs -
#76327
29.4; random segfaults after switch to tree-sitter
Previous Next
Full log
View this message in rfc822 format
"Evgeniy Dushistov via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> 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
This bug report was last modified 116 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.