emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPS make-thread


From: Eli Zaretskii
Subject: Re: MPS make-thread
Date: Sun, 23 Jun 2024 08:53:59 +0300

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Ihor Radchenko <yantar92@posteo.net>,  eller.helmut@gmail.com,
>   emacs-devel@gnu.org
> Date: Sun, 23 Jun 2024 05:18:06 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   ss.c:66: Emacs fatal error: assertion failed: warmest < stackCold
> 
> AFAIR, MPS calls the bottom of a control stack "cold". Warmest could
> then be the other end of the stack. And that's x86, so the stack grows
> down to lower addresses, so that could make sense. Just guessing of course.
> 
> >   lockw3.c:98: Emacs fatal error: assertion failed: lock->claims == 0
> 
> And the typical followup crash from using MPS when it already has
> crashed.
> 
> >   #27 StackScan (ss=0x1fc5fb70, stackCold=0x1edeff28, scan_area=0x2c11f9 
> > <scan_ambig>, closure=0x0) at ss.c:66
> >   #28 0x003c7494 in RootScan (ss=ss@entry=0x1fc5fb70, 
> > root=root@entry=0xa60e83c) at root.c:577
> >   #29 0x003c7d1d in traceScanRootRes (ts=ts@entry=1, rank=rank@entry=0, 
> > arena=arena@entry=0x7100000, root=root@entry=0xa60e83c) at trace.c:528
> >   #30 0x003c8118 in traceScanRoot (root=0xa60e83c, arena=0x7100000, rank=0, 
> > ts=1) at trace.c:545
> 
> No further clue from the backtrace.

Is it safe to call igc--collect from a non-main Lisp thread?  I don't
understand well the semantics and the intent of what igc_collect does,
so I cannot myself try to reason about this.  Maybe what we do there
is not safe when invoked from another Lisp thread?  Do all our threads
share the same arena, for example?  If so, what happens when a Lisp
thread is waiting for the global lock and another Lisp thread calls
igc--collect?

> > We must do something about these assertions: when there's an assertion
> > violation caused by a thread which was started by MPS, we cannot call
> > shut_down_emacs in that thread's context, for obvious reasons.  We
> > must instead set some flag which will cause the main thread or one of
> > the other Lisp threads call shut_down_emacs.  The MPS documentation
> > says:
> >
> >           Warning: The installed assertion handler must not call any
> >           function in MPS, and it must not access memory managed by the
> >           MPS.
> >
> > But our handler, igc_assert_fail, does exactly what they say not to
> > do.
> 
> I know. See the comment above that function.

So how about not calling terminate_due_to_signal from igc_assert_fail?

> One idea might be to set aside a block of memory for use when we know
> that MPS is unusable. Then, make alloc_impl allocate from that block,
> and probably we must put MPS in postmortem state. Or maybe we can just
> use malloc in alloc_impl. 
> 
> I think one should try something like that so that Emacs can do its
> thing as usual in such cases. Can of course fail, and will certainly be
> fiddly. I currently don't have the energy to do that.

One idea would be to exit the non-main Lisp thread (because I think
shutting down Emacs from there is not safe anyway), then shut down
from the main thread.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]