Re: MPS: profiler

[Gerd Möllmann]

Pip Cet <pipcet@protonmail.com> writes:

> 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.

That's basically it, I agree. A signal handler is not supposed to do
things like that, from the POV of MPS (and others :-)).

>
> 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. Unfortunately, the MPS code in current git doesn't
> have facilities to do that, so I've applied this patch to MPS, which
> works here but doesn't for Ihor:
>
> diff --git a/code/protsgix.c b/code/protsgix.c
> index 966569c92..7c60d4fa2 100644
> --- a/code/protsgix.c
> +++ b/code/protsgix.c
> @@ -143,7 +143,7 @@ void ProtSetup(void)
>    int result;
>  
>    sa.sa_sigaction = sigHandle;
> -  result = sigemptyset(&sa.sa_mask);
> +  result = sigfillset(&sa.sa_mask);
>    AVER(result == 0);
>    sa.sa_flags = SA_SIGINFO | SA_RESTART;
>

Hm, sigfillset is a bit much maybe. What about only adding
PROF, like in

  https://www.gnu.org/software/libc/manual/html_node/Blocking-for-Handler.html

But I'll better leave that to the experts.