Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com,
>  emacs-devel@gnu.org
> Date: Mon, 01 Jul 2024 11:47:01 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > As I wrote earlier, these last crashes happened when the only thread
> > running was the Emacs main thread, and MPS code was called from that
> > thread, as side effect of allocating memory (AFAIU).  So the situation
> > with multiple threads is not what we see here.
> 
> May you point me to what in the backtrace is memory allocation?

Here's the top of your original backtrace:

> Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, 
> backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:443
> 443   {
> (gdb) bt
> #0  terminate_due_to_signal (sig=sig@entry=6, 
> backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:443
> #1  0x00005555558634be in set_state (state=IGC_STATE_DEAD) at igc.c:179
> #2  igc_assert_fail (file=<optimized out>, line=<optimized out>, 
> msg=<optimized out>) at igc.c:205
> #3  0x00005555558f1e19 in mps_lib_assert_fail (condition=0x555555943c4c "res 
> == 0", line=126, file=0x555555943c36 "lockix.c")
>     at /home/yantar92/Dist/mps/code/mpsliban.c:87
> #4  LockClaim (lock=0x7fffe8000110) at 
> /home/yantar92/Dist/mps/code/lockix.c:126
> #5  0x00005555558f204d in ArenaEnterLock (arena=0x7ffff7fbf000, recursive=0) 
> at /home/yantar92/Dist/mps/code/global.c:576
> #6  0x000055555591aefe in ArenaEnter (arena=0x7ffff7fbf000) at 
> /home/yantar92/Dist/mps/code/global.c:553
> #7  ArenaAccess (addr=0x7fffeb908758, mode=mode@entry=3, 
> context=context@entry=0x7fffffff97d0) at 
> /home/yantar92/Dist/mps/code/global.c:655
> #8  0x0000555555926202 in sigHandle (sig=<optimized out>, 
> info=0x7fffffff9af0, uap=0x7fffffff99c0) at 
> /home/yantar92/Dist/mps/code/protsgix.c:97
> #9  0x00007ffff3048050 in <signal handler called> () at /lib64/libc.so.6
> #10 0x0000555555827385 in PSEUDOVECTORP (a=XIL(0x7fffeb90875d), code=9) at 
> /home/yantar92/Git/emacs/src/lisp.h:1105
> #11 PROCESSP (a=XIL(0x7fffeb90875d)) at 
> /home/yantar92/Git/emacs/src/process.h:212
> #12 XPROCESS (a=XIL(0x7fffeb90875d)) at 
> /home/yantar92/Git/emacs/src/process.h:224
> #13 handle_child_signal (sig=sig@entry=17) at process.c:7660
> #14 0x000055555573b771 in deliver_process_signal (sig=17, 
> handler=handler@entry=0x555555827200 <handle_child_signal>) at sysdep.c:1758
> #15 0x0000555555820647 in deliver_child_signal (sig=<optimized out>) at 
> process.c:7702
> #16 0x00007ffff3048050 in <signal handler called> () at /lib64/libc.so.6
> #17 0x000055555585f77b in fix_lisp_obj (ss=ss@entry=0x7fffffffa9a8, 
> pobj=pobj@entry=0x7fffeee7ffe8) at igc.c:841
> #18 0x000055555586050d in fix_cons (ss=0x7fffffffa9a8, cons=0x7fffeee7ffe0) 
> at igc.c:1474
> #19 dflt_scan_obj (ss=0x7fffffffa9a8, base_start=0x7fffeee7ffd8, 
> base_limit=0x7fffeee80000, closure=0x0) at igc.c:1578
> #20 dflt_scanx (ss=ss@entry=0x7fffffffa9a8, base_start=<optimized out>, 
> base_limit=0x7fffeee80000, closure=closure@entry=0x0) at igc.c:1658
> #21 0x00005555558613a3 in dflt_scan (ss=0x7fffffffa9a8, base_start=<optimized 
> out>, base_limit=<optimized out>) at igc.c:1669
> #22 0x00005555558f163f in TraceScanFormat (limit=0x7fffeee80000, 
> base=0x7fffeee7e000, ss=0x7fffffffa9a0) at 
> /home/yantar92/Dist/mps/code/trace.c:1539
> #23 amcSegScan (totalReturn=0x7fffffffa99c, seg=0x7fffe845e4c8, 
> ss=0x7fffffffa9a0) at /home/yantar92/Dist/mps/code/poolamc.c:1440
> #24 0x000055555591e7bc in traceScanSegRes (ts=ts@entry=1, rank=rank@entry=1, 
> arena=arena@entry=0x7ffff7fbf000, seg=seg@entry=0x7fffe845e4c8)
>     at /home/yantar92/Dist/mps/code/trace.c:1205
> #25 0x000055555591e9ca in traceScanSeg (ts=1, rank=1, arena=0x7ffff7fbf000, 
> seg=0x7fffe845e4c8) at /home/yantar92/Dist/mps/code/trace.c:1267
> #26 0x000055555591f3a4 in TraceAdvance (trace=trace@entry=0x7ffff7fbfaa8) at 
> /home/yantar92/Dist/mps/code/trace.c:1728
> #27 0x000055555591faa4 in TracePoll
>     (workReturn=workReturn@entry=0x7fffffffab90, 
> collectWorldReturn=collectWorldReturn@entry=0x7fffffffab8c, 
> globals=globals@entry=0x7ffff7fbf008, collectWorldAllowed=<optimized out>) at 
> /home/yantar92/Dist/mps/code/trace.c:1849
> #28 0x000055555591fceb in ArenaPoll (globals=globals@entry=0x7ffff7fbf008) at 
> /home/yantar92/Dist/mps/code/global.c:745
> #29 0x00005555559200da in mps_ap_fill (p_o=p_o@entry=0x7fffffffad00, 
> mps_ap=mps_ap@entry=0x7fffe80017f0, size=size@entry=24)
>     at /home/yantar92/Dist/mps/code/mpsi.c:1097
> #30 0x00005555558601ee in alloc_impl (size=24, type=IGC_OBJ_CONS, 
> ap=0x7fffe80017f0) at igc.c:3330
> #31 0x000055555586023c in alloc (size=size@entry=16, 
> type=type@entry=IGC_OBJ_CONS) at igc.c:3358
> #32 0x000055555586187a in igc_make_cons (car=XIL(0x133e0), cdr=XIL(0)) at 
> igc.c:3385
> #33 0x000055555578e7de in Fcons (car=<optimized out>, cdr=<optimized out>) at 
> alloc.c:2926

As you can see, it all started when we called Fcons, to produce a cons
cell.  That called igc_make_cons, which eventually called MPS
memory-allocation stuff (starting from frame #29).  MPS called us back
(frame #21), and while in fix_lisp_obj, we got delivered SIGPROF, and
attempted to access some memory that was evidently behind the barrier.
The rest is history, because MPS kicked in and tried to take the arena
lock the second time.

There's no other thread anywhere in sight here, this all happens in
the context of our own main (a.k.a. "Lisp") thread.