Re: Anything I should know about thread safety and fprintf?
Re: Anything I should know about thread safety and fprintf?
- Subject: Re: Anything I should know about thread safety and fprintf?
- From: "Jonathan del Strother" <email@hidden>
- Date: Wed, 23 Jan 2008 22:18:47 +0000
On Jan 23, 2008 10:06 PM, Terry Lambert <email@hidden> wrote:
> On Jan 23, 2008, at 11:48 AM, Jonathan del Strother wrote:
> > I keep running into an apparent deadlock within fprintf. I can
> > semi-reliably reproduce it within my application, but have been
> > totally unable to reduce the problem to a smaller test case.
> >
> > In a nutshell, I have two threads calling this -
> > fprintf(stderr, "%s:%d - %s\n", [fileBaseName
> > cStringUsingEncoding:NSASCIIStringEncoding], lineNumber,
> > [formattedMessage cStringUsingEncoding:NSASCIIStringEncoding]);
> >
> > resulting in the following stack trace. The first thread just sits in
> > write$NOCANCEL$UNIX2003() for ever.
> >
> > thread A :
> >
> > #0 0x94709a36 in write$NOCANCEL$UNIX2003 ()
> > #1 0x9470998e in _swrite ()
> > #2 0x947098bb in __sflush ()
> > #3 0x946d4ac8 in __vfprintf ()
> > #4 0x94709603 in vfprintf_l ()
> > #5 0x94709597 in fprintf ()
>
> This is thread A blocked waiting for a write to complete, because it's
> writing to a pipe, socket, network file over a protocol for which the
> server is not currently responding, or other blocking operation.
>
> While it's waiting for this write to complete, it's holding a
> serialization lock on the stdio FILE that it's writing to.
>
>
> > thread B :
> > #0 0x946d392e in semaphore_wait_signal_trap ()
> > #1 0x946db405 in pthread_mutex_lock ()
> > #2 0x94713383 in flockfile ()
> > #3 0x947095e6 in vfprintf_l ()
> > #4 0x94709597 in fprintf ()
>
> This is thread B blocking waiting to acquire the lock currently held
> by thread A.
>
>
> You need to figure out why thread A is blocking. Why it's blocking
> will depend on what type of thing the underlying descriptor for the
> FILE * being written happens to be attached to.
>
> This will most likely boil down to a network connectivity problem, a
> server problem, or a problem with another program that you are trying
> to talk to over a pipe/UNIX domain socket/whatever (i.e. a bug in your
> code).
Hmm. Well I'm not reopening stderr anywhere, so it ought to still be
logging to /var/logs/system.log, or to Xcode's run window. Neither of
which ought to be blocking like that. (Actually, I'm not sure whether
or not I've ever reproduced this when running outside of Xcode. I'll
try it out tomorrow, see if it makes any difference)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden