This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #12847] dprintf/vdprintf can cause fork to fail (child process crash)
- From: Rich Felker <dalias at aerifal dot cx>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 21 Sep 2013 17:42:27 -0400
- Subject: Re: [PATCH][BZ #12847] dprintf/vdprintf can cause fork to fail (child process crash)
- Authentication-results: sourceware.org; auth=none
- References: <20130921191346 dot GA9202 at domone dot kolej dot mff dot cuni dot cz> <20130921194515 dot GF20515 at brightrain dot aerifal dot cx> <20130921202326 dot GA9893 at domone dot kolej dot mff dot cuni dot cz>
On Sat, Sep 21, 2013 at 10:23:26PM +0200, OndÅej BÃlka wrote:
> On Sat, Sep 21, 2013 at 03:45:16PM -0400, Rich Felker wrote:
> > On Sat, Sep 21, 2013 at 09:13:46PM +0200, OndÅej BÃlka wrote:
> > > This bug has a simple patch from Frank Reker in bugzilla, see
> > > http://sourceware.org/bugzilla/show_bug.cgi?id=12847
> > >
> > > Is it ok to commit or is cause somewhere else?
> >
> > dprintf FILEs should not even *be* in this list. That is the
> > underlying bug.
> >
> A code of dprintf looks similar to sprintf, we could mimic sprintf
> logic, however I do not have time to look into it now.
I don't object to your proposed fix as a quick band-aid, but I hope
the larger issue will be fixed. It's utterly stupid that dprintf
requires global locks to insert and remove a FILE in the list of open
FILEs every time you call it, despite there being no need for anything
else to be aware that this temporary FILE structure ever existed.
In principle, there's no good reason dprintf shouldn't be async-signal
safe, and it would be nice if it could eventually be so.
Rich