[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIGPROF + SIGCHLD and igc
From: |
Eli Zaretskii |
Subject: |
Re: SIGPROF + SIGCHLD and igc |
Date: |
Sat, 28 Dec 2024 19:35:54 +0200 |
> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: pipcet@protonmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es,
> emacs-devel@gnu.org, acorallo@gnu.org
> Date: Sat, 28 Dec 2024 17:46:42 +0100
>
> On Sat, Dec 28 2024, Eli Zaretskii wrote:
>
> > Hm... if ArenaEnter uses non-recursive locks, how come we get aborts
> > if some code tries to lock the arena when it is already locked? IOW,
> > how is this situation different from what we already saw several times
> > in the crashes related to having SIGPROF delivered while MPS holds the
> > arena lock?
>
> I'm not sure what you expect instead. It's an error to claim a
> non-recursive lock twice in the same thread. The fault handler claims
> the lock. If the SIGPROF handler interrupts MPS while it's holding the
> lock and then triggers a fault, then it claims the lock a second time.
> It's no surprise to see crashes here.
>
> >> During that time window, the lock is held by the profiler thread. The
> >> SIGPROF handler runs in the main thread. If the main thread tries to
> >> claim the lock, it will block until the profiler thread releases it.
> >
> > See above: I thought that such a situation triggers crashes. I'm
> > probably missing something.
>
> If two threads are claiming a the same non-recursive lock concurrently,
> then it's not an error.
Oh, so you are saying that taking the lock twice is a fatal error only
if that is done from the same thread? Is that known for certain?
> >> >> Regarding deadlocks: the profiler thread holds the lock while it waits.
> >> >> So MPS should not be able to stop the profiler thread there.
> >> >
> >> > Which means we don't register the profiler thread with MPS, right?
> >>
> >> I'm not sure. It may not be safe to call ArenaEnter in non-registered
> >> threads.
> >
> > But if we do register the thread, then MPS _will_ stop it, no?
>
> Good point. But I think we are safe: to access the list of threads to
> stop, MPS must first hold the arena lock.
Are we sure MPS must take the lock before it can stop registered
threads?
- Re: SIGPROF + SIGCHLD and igc, (continued)
- Re: SIGPROF + SIGCHLD and igc, Pip Cet, 2024/12/27
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/27
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Eli Zaretskii, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Eli Zaretskii, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc,
Eli Zaretskii <=
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Eli Zaretskii, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Pip Cet, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Helmut Eller, 2024/12/28
- Re: SIGPROF + SIGCHLD and igc, Pip Cet, 2024/12/29
- Re: SIGPROF + SIGCHLD and igc, Eli Zaretskii, 2024/12/29
- Re: SIGPROF + SIGCHLD and igc, Pip Cet, 2024/12/29
- Re: SIGPROF + SIGCHLD and igc, Pip Cet, 2024/12/29
- Re: SIGPROF + SIGCHLD and igc, Eli Zaretskii, 2024/12/30