This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Don't close or flush stdio streams on abort
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Andreas Schwab <schwab at suse dot de>, libc-alpha at sourceware dot org
- Date: Wed, 8 May 2013 23:51:26 +0200
- Subject: Re: [PATCH] Don't close or flush stdio streams on abort
- References: <mvm4ned3jja dot fsf at hawking dot suse dot de> <20130508101232 dot GA21001 at domone> <mvmr4hh1xxr dot fsf at hawking dot suse dot de> <20130508172315 dot GA20323 at brightrain dot aerifal dot cx>
On Wed, May 08, 2013 at 01:23:15PM -0400, Rich Felker wrote:
> On Wed, May 08, 2013 at 02:02:56PM +0200, Andreas Schwab wrote:
> > OndÅej BÃlka <neleai@seznam.cz> writes:
> >
> > > However removal at stage 4 could cause debugging info not be displayed.
> > > Could it be possible to ignore delivery with something like sigprocmask?
> >
> > Ignore what delivery?
>
> OndÅej seems to be confused that async-signal-safety has to do with
> arrival of a signal while abort() is in progress, rather than calling
> abort() from a signal handler, possibly while the locks are held.
>
Other possible signals, see below.
> With the right types of locks, a trylock operation could be performed
> instead of waiting for a lock. This requires an async-signal-safe,
> reentrant, recursive mutex.
It is most elegant solution but not only way. My comment
was that when you stop other threads and block signals then writing if
they are unlocked can be done with any type of lock. You also do not
worry to unlock correctly as program ends. (Overkill but possible.)
> We have them in musl but I don't know if
> glibc uses a type of lock that could easily be made reentrant. (The
> key trick we use is that, when the lock is held, the reference count
> is one less than the actual number of references, so that there's no
> race window between taking the lock and setting count to 1.)
>
A relevent start is ntpl/lowlevellock.h
Now I noticed other issue there is race condition between aborts from
different threads. Worst thing they can do is to call twice custom
handler. Using atomic increment fixes this.
Ondra