|
Graham Dumpleton
grahamd at dscpl.com.au
Fri Sep 24 22:28:14 EDT 2004
The problem I was having with both Apache 1.3/2.0 and corresponding mod_python for those versions loaded, was that as soon as Apache was started, all the forked processes would crash. [Fri Sep 24 15:06:01 2004] [notice] SIGHUP received. Attempting to restart [Fri Sep 24 15:06:02 2004] [notice] Apache/2.0.51 (Unix) configured -- resuming normal operations [Fri Sep 24 15:06:10 2004] [notice] child pid 15196 exit signal Bus error (10) [Fri Sep 24 15:06:10 2004] [notice] child pid 15194 exit signal Bus error (10) [Fri Sep 24 15:06:10 2004] [notice] child pid 15192 exit signal Bus error (10) [Fri Sep 24 15:06:10 2004] [notice] child pid 15190 exit signal Bus error (10) [Fri Sep 24 15:06:10 2004] [notice] child pid 15188 exit signal Bus error (10) Make the mod_python.c file fix I described and it all works fine. Thus, has nothing to do with command line execution of Python. On 24/09/2004, at 9:13 PM, John Raines wrote: > There's a Macpython IDE that would run a lot of python code and > necessarily initialize some things, I think. Is that really the issue > or are you dealing with python itself from the command line? I'm still > trying to get things working myself and I did download a new version > of python although I think I'm one version behind you on both Apache > and python. > On Sep 24, 2004, at 12:37 AM, Graham Dumpleton wrote: > >> A while back, I posted as to how I managed to get standard Apache 1.3 >> and >> Python 2.3 as supplied with the Mac OS X (10.3.5) operating system, >> working >> with the older mod_python 2.7.10. Specifically, a hack was required >> because >> the Python framework library as supplied with the Mac was appearing to >> already be initialised when mod_python was initialised, even though >> it hadn't. >> The original email and the hack made is attached below. >> >> Anyway, I have now installed Apache 2.0.51 and mod_python 3.1.3 and >> have >> run up against the exact same problem. Remembering, this is with the >> version of Python that comes with the operating system, ie., Python >> 2.3. >> I even rebuilt my box from scratch recently so it is a relatively >> fresh install >> of Mac OS X. >> >> My question is whether anyone running Apache 2.0 and mod_python 3.1.3 >> on Mac OS X, has done so by using the version of Python that comes >> with >> the operating system? The various posts I have seen talk about having >> downloaded the more recent Python 2.3.4 and compiling it from scratch. >> Ie., not using that supplied with the operating system. >> >> If this is the case, and everyone has been building a new version of >> Python, >> it suggests that the problem I am seeing is generic to Python 2.3 >> that comes >> with the Mac and applies to any version of mod_python. Alternatively, >> it >> comes about because of underlying problems with how the loadable >> object >> for mod_python is being created on the Mac. >> >> On Aug 04 21:37, Graham Dumpleton <grahamd at dscpl.com.au> wrote: >>> >>> Subject: Re: [mod_python] Status of Mac OS X / Apache 1.3 / >>> mod_python 2.7.10. >>> >>> On Aug 04 15:26, Justin Ryan <jryan at qutang.net> wrote: >>>> >>>> Subject: Re: [mod_python] Status of Mac OS X / Apache 1.3 / >>>> mod_python 2.7.10. >>>> >>>> Be careful when playing with the file/directory/link/whateva that is >>>> /System/Library/Frameworks/Python.Framework. I ran into some >>>> wierdness >>>> trying to change this into a symlink and move it around (i.e. >>>> change it >>>> back and forth from pointing to Apple's python and my own). >>>> >>>> Also, take care when using the 'python' command after installing >>>> your >>>> own framework build. It's kind of a pain to get a framework build >>>> to >>>> stick python, pythonw, etc.. in /usr/bin - all of my stuff was in >>>> /usr/local/bin, even though I passed --prefix=/usr to the configure >>>> script. >>> >>> I would agree and why I didn't want to go down the path of having to >>> replace >>> the standard version of Python on MacOSX with a newer version to get >>> mod_python >>> to work. Similarly, I didn't want to be replacing their version of >>> Apache. >>> >>> Anyway, listed below is the changes I had to make to get it to build >>> and work >>> on MacOSX (10.3.3) with the standard Python (2.3) and Apache (1.3) >>> that come >>> with the operating system. >>> >>> First off, after running configure, change "src/Makefile" and >>> replace: >>> >>> >>> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ >>> python2.3/config/libpython2.3.a >>> >>> with: >>> >>> -framework Python >>> >>> in LIBS variable. >>> >>> Second, in the same makefile, change CFLAGS and add in: >>> >>> -DEAPI >>> >>> as a compiler option. >>> >>> This will allow mod_python to build, but the result will crash. >>> >>> Final step is to modify src/mod_python.c. The diff is below. There >>> are >>> more comments after that diff as to why the original code is wrong >>> anyway. >>> >>> >>> *** mod_python.c.dist Tue May 29 06:00:41 2001 >>> --- mod_python.c Thu Aug 5 13:21:22 2004 >>> *************** >>> *** 260,265 **** >>> --- 260,268 ---- >>> >>> char buff[255]; >>> >>> + /* fudge for Mac OS X with Apache 1.3 where Py_IsInitialized() >>> broke */ >>> + static int initialized = 0; >>> + >>> /* pool given to us in ChildInit. We use it for >>> server.register_cleanup() */ >>> pool *child_init_pool = NULL; >>> *************** >>> *** 272,279 **** >>> ap_add_version_component(buff); >>> >>> /* initialize global Python interpreter if necessary */ >>> ! if (! Py_IsInitialized()) >>> { >>> >>> /* initialze the interpreter */ >>> Py_Initialize(); >>> --- 275,283 ---- >>> ap_add_version_component(buff); >>> >>> /* initialize global Python interpreter if necessary */ >>> ! if (initialized == 0 || ! Py_IsInitialized()) >>> { >>> + initialized = 1; >>> >>> /* initialze the interpreter */ >>> Py_Initialize(); >>> >>> >>> The problem on MacOSX is that Py_IsInitialized() is returning true >>> on the >>> first time it is called even though Python hadn't up until that >>> point actually >>> been initialised. This means initialisation is skipped and the first >>> time >>> something tries to use Python methods later, it crashes. >>> >>> To my mind the use of Py_IsInitialized() is partly bogus anyway. >>> This is >>> because if someone did come up with a different apache module which >>> also tried to use Python and it got loaded first and called >>> Py_Initialize(), >>> it would mean when mod_python got loaded it would skip initialisation >>> and wouldn't initialise as a result the "interpreters" dictionary >>> nor would >>> it necessarily initialise threading if the other module didn't do it. >>> >>> Thus, even though people might reckon that this patch may only be >>> relevant to the MacOSX problem I have, I would disagree, because I >>> would >>> say the code is wrong anyway. >>> >>> As a demonstration, you might modify the code and add an extra call >>> to >>> Py_Initialize() just prior to the "if" statement where >>> Py_IsInitialized() is >>> called as if it was done somewhere else. Do this and mod_python >>> should >>> by observation break since "interpreters" will never get set as >>> described above. >>> >>> -- >>> Graham Dumpleton (grahamd at dscpl.com.au) >>> _______________________________________________ >>> Mod_python mailing list >>> Mod_python at modpython.org >>> http://mailman.modpython.org/mailman/listinfo/mod_python >>> >>> >> >> -- >> Graham Dumpleton (grahamd at dscpl.com.au) >> _______________________________________________ >> Mod_python mailing list >> Mod_python at modpython.org >> http://mailman.modpython.org/mailman/listinfo/mod_python >> > > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python
|