Re: Debugging __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
Re: Debugging __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
- Subject: Re: Debugging __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
- From: Ken Thomases <email@hidden>
- Date: Thu, 10 Apr 2008 14:44:39 -0500
On Apr 10, 2008, at 7:59 AM, Jerry wrote:
On 9 Apr 2008, at 14:18, Ken Thomases wrote:
On Apr 8, 2008, at 12:57 PM, Jerry wrote:
We're getting a load of messages of the form:
Break on
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNC
TIONALITY___YOU_MUST_EXEC__() to debug.
The process has forked and you cannot use this CoreFoundation
functionality safely. You MUST exec().
from a thirdparty library we're using. The trouble is, when run
under gdb, the messages go away, and my breakpoint isn't hit. How
can I debug this and find out what's being called?
You can try to use DTrace:
sudo dtrace -n 'pid$target::
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCT
IONALITY___YOU_MUST_EXEC__:entry {ustack();}' -c "/path/to/program
arg1 arg2 ..."
(Note that this will run your program as root. To avoid that,
remove the -c <cmd> option and replace it with -p <pid>, which
requires that your program already be running but has not yet hit
the problem you're trying to diagnose.)
Thanks for the suggestion. I had to make one fix to the command
line: remove the space after pid$target::.
Mail text wrapping added that.
Unfortunately, although I still get the messages, I don't get any
output from dtrace.
Oh, duh. My bad. It's the child process which is encountering the
error, and the child process obviously has a different pid.
That's a nuisance. I don't know how to tell dtrace to follow a fork
to child processes, or to trace using the pid provider for a
prospective process. Huh.
Interestingly, if I use "fork" as the symbol to check for, I do get
output but the stack trace for fork doesn't appear until a long
time after I get the "THE_PROCESS_HAS_FORKED..." messages. Weird.
I've also checked for vfork with no hits. I suppose it's back to
the binary code chopping to isolate this, but the whole application
is so interdependent, it's hard to do :-(
To trace for fork or vfork, you can use the syscall provider, which
is system-wide and not pid-specific:
sudo dtrace -n 'syscall::*fork*:return / execname ==
"NameOfYourExecutable" / {ustack();}'
That will show you where fork is being called. Naturally, the stack
in the child will be the same as that in the parent, which gives you
a starting point to look in the code. There really should not be
much "code distance" between that point and the exec*() call,
although the crash you're seeing suggests there might be. Basically,
there's a _very_ limited set of things which are allowed to be done
between a fork() and exec() in the child.
Search for "fork" in the following for some background: <http://
developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html>
Good luck,
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