Re: SIGTRAP after writing to socket
Re: SIGTRAP after writing to socket
- Subject: Re: SIGTRAP after writing to socket
- From: Stefan Werner <email@hidden>
- Date: Wed, 13 Dec 2006 14:34:26 +0100
On Dec 13, 2006, at 12:31 PM, Quinn wrote:
This raises a couple of interesting questions:
A. Why is the Mach message send failing?
B. Why is Foundation calling CFRunLoopWakeUp?
I don't have a good answer to A. The best I can suggest is that
you set a breakpoint on CFRunLoopWakeUp and step through it (at the
assembly level, using GDB's "ni" command) and see what the return
value of __CFSendTrivialMachMessage is. My guess is that the
wakeup port has somehow been closed.
With regards point B, I looked this up in the Foundation sources
and it looks like the thread that's executing this code is an
internal thread that's created by Foundation's NSTask to wait for
process termination. This thread starts up and calls
_waitForTermination which waits for a particular child process to
terminate (using <x-man-page://2/wait4>). When that happens, it
wakes up (using CFRunLoopWakeUp) the runloop associated with the
NSTask object. It's this wakeup that's dying with a HALT.
Thank you! That was the missing piece of information. I wasn't aware
of the extra thread that tries to access the runloop that created the
NSTask. What's happening in my code (and working without hiccups on
10.4) is that the (p)thread that created the NSTask may not exist any
more at the time when that happens. I was making the assumption that
since the process spawned by NSTask could live longer than the NSTask
object (at least this is what the documentation of
NSTaskDidTerminateNotification implies), this would also apply to the
thread in which this NSTask was created. This seems to be where
10.3.9 behaves differently than 10.4. Inserting a [theTask
waitUntilExit] before [mTask release] fixed it, I longer receive
SIGTRAPs.
My apologies for causing confusion by pointing at write() to quickly
- it seems that the network operations only caused different life
times of the subprocess and the launching thread, but were not
directly responsible for the SIGTRAP.
Thanks again,
Stefan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden