emacs-devel
[Top][All Lists]
Advanced

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

Re: MPS: profiler


From: Eli Zaretskii
Subject: Re: MPS: profiler
Date: Fri, 21 Jun 2024 13:43:14 +0300

> Date: Fri, 21 Jun 2024 08:23:16 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: emacs-devel@gnu.org, Gerd Möllmann <gerd.moellmann@gmail.com>, Eli 
> Zaretskii <eliz@gnu.org>, eller.helmut@gmail.com
> 
> On Thursday, June 20th, 2024 at 19:24, Ihor Radchenko <yantar92@posteo.net> 
> wrote:
> > I am playing around with scratch/igc branch for fun, and there is one
> > crash that I can reproduce quite consistently.
> > 
> > All it takes is (1) compile Emacs without native-compilation support;
> > (2) open Emacs; (3) M-x profiler-start; (4) run a complex operation.
> > 
> > Steps to reproduce:
> > 
> > 1. emacs -Q doc/misc/org.org
> > 2. M-x profiler-start RET cpu RET
> > 3. M-: (org-element-parse-buffer) RET
> > 
> > Without step 2, no crash.
> 
> Just sharing some information from a private discussion with Ihor:
> 
> I can reproduce this locally. I can also "fix" it locally, but the problem 
> seems more complicated since Ihor reports the fix isn't working for him.
> 
> 1. MPS uses SIGSEGV internally, usually transparently to the client program.
> 
> 2. The profiler uses SIGPROF, then runs complicated code in the handler. My 
> understanding is it's carefully tuned not to trigger traditional GC, but it 
> can and will cause (handled) SIGSEGV.
> 
> 3. MPS isn't reentrant enough to handle a SIGSEGV while it's handling a 
> SIGSEGV, and will die with one of a number of errors.

This is not what happens in this case, so let's stick to what we
actually see, okay?  It's complex enough.

> The right thing to do, IMHO, is to let MPS know that it should block SIGPROF 
> (and any other signals that might use managed memory) while handling SIGSEGV.

I disagree.  MPS must be able to support programs compiled with
"-gprof", so I don't believe SIGPROF should be blocked.  The handler
is our code, so we should modify the handler not to do anything unsafe
if SIGPROF happens while MPS is processing its SIGSEGV.  That's a much
more reliable fix, and one that will allow us to keep our profiling
code.



reply via email to

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