Re: Unix Signals Delivered from Quitting Cocoa Apps?
Re: Unix Signals Delivered from Quitting Cocoa Apps?
- Subject: Re: Unix Signals Delivered from Quitting Cocoa Apps?
- From: aaron smith <email@hidden>
- Date: Mon, 13 Sep 2010 01:05:45 -0700
Thanks for pointing that I can't use high level frameworks in a child.
I'll set up everything I need for the execvp call before the actual
fork.
AH! I totally missed that I need to use an int to store the child exit
status info.
Here's a version that works now..
http://pastebin.org/860040
Thanks!
On Mon, Sep 13, 2010 at 12:47 AM, Ken Thomases <email@hidden> wrote:
> On Sep 13, 2010, at 2:30 AM, aaron smith wrote:
>
>> I'm working on a test to catch when an application crashes, and launch
>> another executable (eventually crash reporter).
>>
>> I'm exhibiting strange behavior - whenever I quit the application
>> normally, the information I'm getting back about what happened and why
>> it stopped is always a signal, but the signal is never the same.
>
> You're using the wait() call incorrectly. The return value on success is a PID, not the status. (You've understood that at least once, since you compare it to the child PID.) The status is output through a parameter.
>
> Note the values you posted and how they're monotonically increasing (7095, 7136, 7151). PIDs.
>
> So, the values you're seeing are not signals. They're garbage.
>
>
> That said, you have a more fundamental problem. It is not valid to run Cocoa or Core Foundation or any high-level framework in a child after a fork() and before an exec*(). Apple has made note of this here and there. Unfortunately, the clearest description is no longer online. It's in the Leopard release notes for Core Foundation. If you install the Leopard Core Library docset into Xcode, you can find it in there.
>
> Here is what it says:
>
>> CoreFoundation and fork()
>>
>> Due to the behavior of fork(), CoreFoundation cannot be used on the child-side of fork(). If you fork(), you must follow that with an exec*() call of some sort, and you should not use CoreFoundation APIs within the child, before the exec*(). The applies to all higher-level APIs which use CoreFoundation, and since you cannot know what those higher-level APIs are doing, and whether they are using CoreFoundation APIs, you should not use any higher-level APIs either. This includes use of the daemon() function.
>>
>> Additionally, per POSIX, only async-cancel-safe functions are safe to use on the child side of fork(), so even use of lower-level libSystem/BSD/UNIX APIs should be kept to a minimum, and ideally to only async-cancel-safe functions.
>>
>> This has always been true, and there have been notes made of this on various Cocoa developer mailling lists in the past. But CoreFoundation is taking some stronger measures now to "enforce" this limitation, so we thought it would be worthwhile to add a release note to call this out as well. A message is written to stderr when something uses API which is definitely known not to be safe in CoreFoundation after fork(). If file descriptor 2 has been closed, however, you will get no message or notice, which is too bad. We tried to make processes terminate in a very recognizable way, and did for a while and that was very handy, but backwards binary compatibility prevented us from doing so.
>
> Regards,
> Ken
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden