Re: debug a forked PTY process
Re: debug a forked PTY process
- Subject: Re: debug a forked PTY process
- From: Ken Thomases <email@hidden>
- Date: Mon, 8 Mar 2010 10:29:21 -0600
On Mar 8, 2010, at 9:23 AM, Nadav Tenenbaum wrote:
> what this class does is to fork a PTY process and then provide an interface to it, kind of like NSTask
>
> the problem is that when debugging using gdb, the following error appears a lot of times:
> The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
> Break on __THE_PROCESS_HAS_FORKED_AND_
> YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
>
> what does this mean and what can I do with that?
I can't find the Leopard CoreFoundation release notes online, but it's in the Leopard Core Library docset that you can install in Xcode. In those release notes is the following:
> 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.
In other words, it has never been safe to do very much after a fork(). If that's what PTYTask is doing, then it's buggy.
This doesn't have much to do with debugging, I don't think. It's just that, previously, the output was going to the console log and you weren't noticing it.
Regards,
Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden