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: Jerry <email@hidden>
- Date: Fri, 11 Apr 2008 09:07:29 +0100
On 10 Apr 2008, at 20:44, Ken Thomases wrote:
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_FUNCTIONALITY___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_FUNCTIONALITY___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.
This gives the same results: I get all the warning mesaages and then
some time later, dtrace reports the fork. It seems that the output of
dtrace is being delayed somewhat, because the stack trace it reports
appears to be correct and showed that something being called by Python
was the problem: By binary chopping the code, I've isolated it to the
Python platform.system() call, which does a popen(). We're also using
Tcl in our application and this information led me to http://bugs.python.org/issue1676
where it seems other people are running into the same problem with
the combination of Tcl and Python. I think we have a fix by rebuilding
the Tcl libraries in a different way.
Thanks for the help,
Jerry
_______________________________________________
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