Re: MPS make-thread

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Helmut Eller <eller.helmut@gmail.com>, Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org
> Date: Fri, 21 Jun 2024 19:58:54 +0000
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
> > Pushed, please check.
> 
> Now, there is no crash when I run my code that creates threads, but
> there is a crash soon after :(

What did you run to get this?  AFAIU, the recipe used batch mode, in
which case there's no "soon after", because Emacs exits.

I see in the backtrace Fdelete_process, so what process was that and
how was it run?

Running xbacktrace after "bt" should produce useful info by showing us
the Lisp backtrace, so always try to do that (unless you know that
"xbacktrace" crashes in the particular situation).

And I think there's another problem here:

> Thread 1 "emacs" received signal SIGABRT, Aborted.
> 0x00007ffff58ae9fb in pthread_kill () from /lib64/libc.so.6
> (gdb) bt
> #0  0x00007ffff58ae9fb in pthread_kill () at /lib64/libc.so.6
> #1  0x00007ffff58553d2 in raise () at /lib64/libc.so.6
> #2  0x00005555556bba66 in terminate_due_to_signal (sig=sig@entry=6, 
> backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:481
> #3  0x00005555557b2ec9 in igc_assert_fail (file=<optimized out>, 
> line=<optimized out>, msg=<optimized out>) at igc.c:158
> #4  0x000055555582fe29 in mps_lib_assert_fail (condition=0x55555588ff52 "res 
> == 0", line=126, file=0x55555588ff3c "lockix.c")
>     at /home/yantar92/Dist/mps/code/mpsliban.c:87
> #5  LockClaim (lock=0x7fffe8000110) at 
> /home/yantar92/Dist/mps/code/lockix.c:126
> #6  0x000055555583005d in ArenaEnterLock (arena=0x7ffff7fc2000, recursive=0) 
> at /home/yantar92/Dist/mps/code/global.c:576
> #7  0x000055555585e09c in ArenaEnter (arena=0x7ffff7fc2000) at 
> /home/yantar92/Dist/mps/code/global.c:553
> #8  mps_ap_fill (p_o=p_o@entry=0x7fffffffa490, 
> mps_ap=mps_ap@entry=0x7fffe8001770, size=size@entry=24) at 
> /home/yantar92/Dist/mps/code/mpsi.c:1094
> #9  0x00005555557b444c in alloc_impl (size=24, type=IGC_OBJ_CONS, 
> ap=0x7fffe8001770) at igc.c:3159
> #10 0x00005555557b454a in alloc (size=size@entry=16, 
> type=type@entry=IGC_OBJ_CONS) at igc.c:3177
> #11 0x00005555557b5f24 in igc_make_cons (car=car@entry=0x2, 
> cdr=cdr@entry=0x0) at igc.c:3204
> #12 0x000055555571f922 in Fcons (cdr=0x0, car=0x2) at alloc.c:2926
> #13 list2 (arg1=arg1@entry=0x7f20, arg2=arg2@entry=0x2) at alloc.c:2978
> #14 0x000055555578913c in Fdelete_process (process=0x7fffae000ffd) at 
> process.c:1124
> #15 0x00005555557916b0 in kill_buffer_processes (buffer=buffer@entry=0x0) at 
> process.c:8289
> #16 0x00005555556bb797 in shut_down_emacs (sig=sig@entry=6, 
> stuff=stuff@entry=0x0) at emacs.c:3140
> #17 0x00005555556bba2f in terminate_due_to_signal (sig=sig@entry=6, 
> backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:464
> #18 0x00005555557b2ec9 in igc_assert_fail (file=<optimized out>, 
> line=<optimized out>, msg=<optimized out>) at igc.c:158
> #19 0x000055555584d2ae in mps_lib_assert_fail (condition=0x55555588c9ee 
> "SigCheck Thread: thread", line=67, file=0x55555588ca06 "thix.c")
>     at /home/yantar92/Dist/mps/code/mpsliban.c:87
> #20 ThreadCheck (thread=0x7fff98184c40) at 
> /home/yantar92/Dist/mps/code/thix.c:67

As you see, MPS hit an assertion violation, which causes us to call
shut_down_emacs.  shut_down_emacs does all kinds of cleanups and
attempts to auto-save unsaved edits, but while doing so it could
re-enter MPS, which happens here.  Should we do something, like park
the arena, early on in shut_down_emacs to allow the auto-saving and
cleanups to run without crashing?  Or maybe ignore (some) assertions
that happen during the cleanup?

Btw, is this the debug build of MPS or a production build?  IOW, is
the second assertion, in mps_lib_assert_fail, expected in a production
build?  AFAIU, that assertion is hit because we re-enter the arena,
and its lock is already taken.