emacs-devel
[Top][All Lists]
Advanced

[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?



reply via email to

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