bug#75689: 31.0.50; feature/igc: crash after calling 'mu4e'

[Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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