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 <k...@codeweavers.com> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
