Re: MPS: a random backtrace while toying with gdb

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com,  yantar92@posteo.net,  emacs-devel@gnu.org,
>   eller.helmut@gmail.com
> Date: Sun, 30 Jun 2024 11:43:56 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Which unsafe function did we call in this case, though?  AFAICT, we
> > simply accessed memory that happens to be behind the barrier:
> >
> >   #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
> >
> > Line 7660 of process.c is this:
> >
> >       struct Lisp_Process *p = XPROCESS (proc);
> >
> > What "crime" did we commit here?
> 
> Not a crime, but we are using a lib that we know uses barriers and
> functions of which get invoked when we hit such a barrier. We can't just
> ignore that.

What alternatives do we have?  Emacs code deals with Lisp objects and
memory managed by MPS all over the place.  In many case, the
programmer doesn't necessarily know whether some data is or isn't in
memory managed by MPS.

You are asking to do the impossible, IMO.  Refraining from touching
MPS-managed memory from signal handlers is simply not practical in
Emacs.  E.g., it would make the profiler useless, because the minimum
you must do from the signal handler is to see which Lisp function is
being run; if you defer this for later, you will see a completely
skewed profile.