GNU bug report logs - #75689
31.0.50; feature/igc: crash after calling 'mu4e'

Previous Next

Full log

Message #8 received at 75689 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: 75689 <at> debbugs.gnu.org
Subject: bug#75689: 31.0.50; feature/igc: crash after calling 'mu4e'
Date: Wed, 05 Feb 2025 09:04:39 +0000

This bug report never made it into my inbox, so I only discovered it on
debbugs just now.

Here's the backtrace:

> Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=11, backtrace_limit=40) at /home/reitero/build/sources/emacs/emacs/src/emacs.c:432
> 432	{
> (gdb) bt
> #0  terminate_due_to_signal (sig=11, backtrace_limit=40) at /home/reitero/build/sources/emacs/emacs/src/emacs.c:432
> #1  0x00005555556d3512 in handle_fatal_signal (sig=sig <at> entry=11) at /home/reitero/build/sources/emacs/emacs/src/sysdep.c:1799
> #2  0x00005555556d0bf9 in deliver_thread_signal (sig=sig <at> entry=11, handler=handler <at> entry=0x5555556d3504 <handle_fatal_signal>) at /home/reitero/build/sources/emacs/emacs/src/sysdep.c:1791
> #3  0x00005555556d0c5d in deliver_fatal_thread_signal (sig=sig <at> entry=11) at /home/reitero/build/sources/emacs/emacs/src/sysdep.c:1811
> #4  0x00005555556d0c8e in handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at /home/reitero/build/sources/emacs/emacs/src/sysdep.c:1949
> #5  <signal handler called>
> #6  0x00007ffff364c3db in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
> #7  0x000055555585fc17 in sigHandle ()
> #8  <signal handler called>
> #9  0x000055555579454c in igc_header_nwords (h=0x7fffe24599a8) at /home/reitero/build/sources/emacs/emacs/src/igc.c:663
> #10 0x0000555555794563 in obj_size (h=<optimized out>) at /home/reitero/build/sources/emacs/emacs/src/igc.c:694
> #11 0x000055555579cfdb in dflt_skip (base_addr=0x7fffe24599a8) at /home/reitero/build/sources/emacs/emacs/src/igc.c:1742
> #12 0x00005555558699bd in amcSegFix ()
> #13 0x0000555555803aad in _mps_fix2 ()
> #14 0x000055555579c985 in fix_raw (ss=ss <at> entry=0x7fffffffacb8, p=p <at> entry=0x7fffffffab30) at /home/reitero/build/sources/emacs/emacs/src/igc.c:1161
> #15 0x000055555579ca43 in fix_string (ss=ss <at> entry=0x7fffffffacb8, s=s <at> entry=0x7fffbe88c2c8) at /home/reitero/build/sources/emacs/emacs/src/igc.c:1754
> #16 0x00005555557a1a7c in dflt_scan_obj (ss=ss <at> entry=0x7fffffffacb8, base_start=base_start <at> entry=0x7fffbe88c2c8, base_limit=base_limit <at> entry=0x7fffbe88c338, closure=closure <at> entry=0x0)
>     at /home/reitero/build/sources/emacs/emacs/src/igc.c:2021
> #17 0x00005555557a1c2f in dflt_scanx (ss=ss <at> entry=0x7fffffffacb8, base_start=<optimized out>, base_limit=0x7fffbe88c338, closure=closure <at> entry=0x0) at /home/reitero/build/sources/emacs/emacs/src/igc.c:2088
> #18 0x00005555557a1c6b in dflt_scan (ss=0x7fffffffacb8, base_start=<optimized out>, base_limit=<optimized out>) at /home/reitero/build/sources/emacs/emacs/src/igc.c:2099
> #19 0x0000555555835165 in amcSegScan ()
> #20 0x0000555555864340 in traceScanSegRes ()
> #21 0x000055555586452a in traceScanSeg ()
> #22 0x0000555555865386 in TraceAdvance ()
> #23 0x0000555555865b4d in TracePoll ()
> #24 0x0000555555865db9 in ArenaPoll ()
> #25 0x00005555558661a3 in mps_ap_fill ()
> #26 0x00005555557a0cd7 in alloc_impl (size=104, size <at> entry=98, type=type <at> entry=IGC_OBJ_STRING_DATA, ap=0x7fffe8001a40) at /home/reitero/build/sources/emacs/emacs/src/igc.c:3976
> #27 0x00005555557a0dc6 in alloc (size=size <at> entry=98, type=type <at> entry=IGC_OBJ_STRING_DATA) at /home/reitero/build/sources/emacs/emacs/src/igc.c:4004
> #28 0x00005555557a0e59 in alloc_string_data (nbytes=nbytes <at>
> entry=89, clear=clear <at> entry=false) at
> /home/reitero/build/sources/emacs/emacs/src/igc.c:4058
> #29 0x00005555557a0f8b in igc_make_string (nchars=89, nbytes=89, unibyte=unibyte <at> entry=false, clear=false) at /home/reitero/build/sources/emacs/emacs/src/igc.c:4121

I'm not sure I can do much without a "bt full" backtrace in this
situation (and it's probably too late for that :-) ).

The unusal thing I can see is that we were in igc_make_string, where we
had allocated a string object but not yet filled its data pointer with a
valid string data pointer.  IIUC, that means s->u.s.data was still NULL
at that point.

But then GC got triggered, and we did blindly subtracted 8 from a NULL
pointer to find the "data pointer", and passed 0xfffffffffffffff8 to
MPS.  However, in my experiments, that works out fine:
0xfffffffffffffff8 isn't a valid MPS pointer, so it "fixes" to itself,
and we write back a new NULL pointer.

So that's a situation we might want to handle better, but not what led
to the crash, I think, unless something else also went wrong.

Sorry, no further ideas here for now.

Pip

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.