An error message in apache in Mac OS X 10.5.1: The process has forked ...
Hang-A
I'm trying to deploy my web application by using wsgi.
I'm using Mac OS X 10.5.1 Leopard, MacPython 2.5 (compiled as a 32-
bit), Apache2 (originally compiled as a 64-bit, but downgraded to a 32-
bit on according to modwsgi guideline). My machine is PPC 64-bit.
My application is using a python package called soaplib, which depends
on cElementTree written in C.
Since a so file for cElementTree wasn't compiled for 4 mac
architectures, I downgraded apache to 32-bit one. My hello example
using the soaplib works without any problem, but another application
using soaplib package runs for the first time but whenever I invoke
the service from a client apache raises the following error:
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.
[Wed Jan 30 16:58:24 2008] [notice] child pid 98548 exit signal Trace/
BPT trap (5)
I changed httpd.conf file to run each application as a demon process
as explained in mod_wsgi guideline, but this change didn't have any
effects.
If some of you have similar problems, please let me know how I can
solve this problem.
In terms of web server administration and C compiling, I don't have
enough knowledge.
So, if you also point me to somewhere I can study more to solve the
problem, it'll be also grateful!
Thanks,
from Myunghwa Hwang
Graham Dumpleton
>
> Hello!
>
> I'm trying to deploy my web application by using wsgi.
> I'm using Mac OS X 10.5.1 Leopard, MacPython 2.5 (compiled as a 32-
> bit),
Is there any reason you can't use the standard Python 2.5.1 that comes
with Mac OS X 10.5?
> Apache2 (originally compiled as a 64-bit, but downgraded to a 32-
> bit on according to modwsgi guideline). My machine is PPC 64-bit.
Hmmm, I new that the fat binary problem was an issue with Intel,
didn't know it was also an issue with PPC.
> My application is using a python package called soaplib, which depends
> on cElementTree written in C.
> Since a so file for cElementTree wasn't compiled for 4 mac
> architectures, I downgraded apache to 32-bit one. My hello example
> using the soaplib works without any problem, but another application
> using soaplib package runs for the first time but whenever I invoke
> the service from a client apache raises the following error:
> 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.
> [Wed Jan 30 16:58:24 2008] [notice] child pid 98548 exit signal Trace/
> BPT trap (5)
I've seen discussion of this error before, but not with mod_wsgi. Can
you perhaps try the standard OS version of Python while I do some more
research on what the error actually means.
Graham
Graham Dumpleton
> > on cElementTree written in C.
> > Since a so file for cElementTree wasn't compiled for 4 mac
> > architectures, I downgraded apache to 32-bit one. My hello example
> > using the soaplib works without any problem, but another application
> > using soaplib package runs for the first time but whenever I invoke
> > the service from a client apache raises the following error:
> > 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.
> > [Wed Jan 30 16:58:24 2008] [notice] child pid 98548 exit signal Trace/
> > BPT trap (5)
>
> I've seen discussion of this error before, but not with mod_wsgi. Can
> you perhaps try the standard OS version of Python while I do some more
> research on what the error actually means.
BTW, it might help if you can get a stack trace for where this is
occurring. Use the procedure for debugging a mod_wsgi daemon process
with gdb described in:
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
Ie., attach to daemon process and then set a breakpoint of that bug
function name above.
break __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
Then trigger you request and when gdb drops back to prompt, run:
where
Post the stack trace. This will help to identify which specific code
library and/or module you are using which is causing the problem.
Graham
Hang-A
Though I solved this problem by accident, I will try the debugging
with gdb also.
How I solved is the following:
I've checked which so file has dependencies on
CoreFoundation.framework.
I've got the idea while reading your document of Application Issues.
Anyway, I found out that phpcups.so is dependent on that framework and
my apache is loading libphp5.so.
Since I couldn't find any dependencies from other so files in python
package directories,
in httpd.conf I commented out the loading of libphp5.so.
After restarting apache, the client code ran without any problem.
Since I'm not using PHP, this is a solution for me.
However, I cannot understand how running a python application affects
the relationship between php and apache.
The debugging might give a clue for that.
Thanks!
from Myunghwa
On Feb 7, 3:55 pm, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
Hang-A
My previous remedy for the Process_Forked error turned out not to be a
solution.
I reconfigured the apache setup, now wsgi applications are in embedded
mode.
Unlike the previous case, the Process_Forked error does not stop
Apache, so now it's like a warning message.
And it happens whenever my application tries to write a file in the
local disk.
My applications work despite the warning message, but is there a way
to prevent this problem?
I tried to use gdb or pdb, but since my applications are based on soap-
based messaging,
when a client sends a message to the server, the server just hangs
out. So I couldn't work with the debugging mode.
Graham Dumpleton
the problem? Dependencies on soaplib and cElementTree okay, but if you
can make example not dependent on having backend service to talk to,
would be preferable.
If you can do that, can see whether 64 bit Intel Leopard shows problem.
BTW, is there any reason why you couldn't recompile cElementTree so it
had all architectures and thus avoid crippling your Apache to run in
32 bit mode?
Graham
stada
In my case this error caused by php gd, don't know how to fix this.
I use Mac OS X 10.5.2 Intel. Apache and php compiled in Intel 32-bit
Graham Dumpleton
>
> I got this error too
>
> In my case this error caused by php gd, don't know how to fix this.
>
> I use Mac OS X 10.5.2 Intel. Apache and php compiled in Intel 32-bit
For PHP GD, does the very end of the following discussion help:
http://discussions.apple.com/message.jspa?messageID=5705589
In the case of GD, it relates to use of FreeType library, which makes
some Carbon API calls.
I don't understand why OP would have an issue with cElementTree as
wouldn't have expected it to be be making Carbon API calls or even
using a library which would.
Graham
Graham Dumpleton
Another comment on this problem, and since prior mail lost context, am
talking about:
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
with Python, although the Python interpreter is created in Apache
parent process and is passed through a fork, all the Python modules
used by an application are only loaded after the fork. This means that
even if a Python module used Carbon library directly or indirectly,
this problem shouldn't occur as library would only be loaded after
fork and thus would incur the fork.
Thus, the problem can only be because of something loading the Carbon
library in some way when in context of Apache parent process. If PHP
preloads its module in Apache parent process rather than loading them
after fork and Apache child process created, then it would be the
cause, I can't see how it could be Python.
Thus first step would appear to be to disable PHP in Apache and see if
problems in Python go away. If even after doing that and only thing
being loaded is Python and problem still occurs, then would be more
worried.
Graham