|
Graham Dumpleton
grahamd at dscpl.com.au
Thu Oct 13 00:12:26 EDT 2005
The mod_python.so in your Apache modules directory, or wherever it is picking it up from, appears to still be that for mod_python 2.7.X. Thus, find LoadModule instruction for mod_python in Apache config and work out where it is loading it from. Ensure that that module is that for mod_python 3.2. Graham Peter Sanchez wrote .. > Maybe I am not understanding what you are saying... > > So I just deinstalled mod_python completely, verified that the > directory /usr/local/lib/python2.4/site-packages/mod_python directory > was gone. I reinstalled and the directory was there with all the other > files included (apache.py, etc.) > > The same problem exists. Is it an Apache compilation issue? > > Sorry if I am being slow on this issue... > > Thanks, > > Peter > > On 10/12/05, Graham Dumpleton <grahamd at dscpl.com.au> wrote: > > Now I am even more blind. I got that the wrong way around. You > > have the 3.2 mod_python.apache module, but the Apache module > > is still that for 2.7. Ie., only mod_python Apache module for 2.7 > > would be attempting to call init() with 0 arguments where 2 is > > expected. > > > > This would explain why thread state problem is still there as Apache > > module hasn't changed. > > > > Blame Apple for this, trying to read up on the new video iPod and > > it is distracting my thoughts. :-) > > > > Graham > > > > On 13/10/2005, at 8:04 AM, Graham Dumpleton wrote: > > > > > Okay, I am blind. Unfortunate that the thread state problem didn't > > > go away, but only just noticed in the error messages the init() > > > call argument mismatch. > > > > > > The problem you are having is that the Apache module is for > > > mod_python 3.2, but it is still finding the Python modules, ie., > > > the mod_python.apache module, from your old mod_python 2.7 > > > installation. > > > > > > In 2.7, init() took no arguments. In 3.2 it takes two arguments. > > > > > > Sorry, didn't notice that before. Thus, get rid of the mod_python 2.7 > > > Python modules and ensure 3.2 versions are installed correctly. > > > > > > Still think something isn't right with the thread state deletion > > > code. Are you absolutely sure that your newly compiled Apache > > > module is being used? > > > > > > Graham > > > > > > On 12/10/2005, at 9:33 AM, Peter Sanchez wrote: > > > > > >> Well, I did the patches you suggested, and it didn't help much. > > >> Here is the log snippet: > > >> > > >> [Tue Oct 11 16:17:07 2005] [notice] Apache/2.0.54 (FreeBSD) PHP/ > > >> 4.4.0 mod_python/3.2.0b Python/2.4.1 configured -- resuming normal > > >> operati > > >> ons > > >> [Tue Oct 11 16:17:07 2005] [notice] child pid 71664 exit signal > > >> Abort trap (6) > > >> [Tue Oct 11 16:17:07 2005] [notice] child pid 71663 exit signal > > >> Abort trap (6) > > >> [Tue Oct 11 16:17:07 2005] [notice] child pid 71660 exit signal > > >> Abort trap (6) > > >> [Tue Oct 11 16:17:07 2005] [notice] child pid 71654 exit signal > > >> Abort trap (6) > > >> [Tue Oct 11 16:17:07 2005] [notice] child pid 71640 exit signal > > >> Abort trap (6) > > >> [Tue Oct 11 16:17:07 2005] [notice] child pid 71634 exit signal > > >> Abort trap (6) > > >> [Tue Oct 11 16:17:07 2005] [notice] child pid 71624 exit signal > > >> Abort trap (6) > > >> [Tue Oct 11 16:17:07 2005] [notice] child pid 69509 exit signal > > >> Abort trap (6) > > >> [Tue Oct 11 16:17:07 2005] [notice] child pid 69490 exit signal > > >> Abort trap (6) > > >> [Tue Oct 11 16:17:07 2005] [notice] child pid 69470 exit signal > > >> Abort trap (6) > > >> [Tue Oct 11 16:17:07 2005] [notice] child pid 69437 exit signal > > >> Abort trap (6) > > >> [Tue Oct 11 16:17:07 2005] [error] make_obcallback: could not call > > >> init.\n > > >> TypeError: init() takes exactly 2 arguments (0 given) > > >> Fatal Python error: PyThreadState_Delete: tstate is still current > > >> [Tue Oct 11 16:17:08 2005] [notice] child pid 71632 exit signal > > >> Abort trap (6) > > >> [Tue Oct 11 16:17:09 2005] [error] make_obcallback: could not call > > >> init.\n > > >> TypeError: init() takes exactly 2 arguments (0 given) > > >> > > >> > > >> Over and over again ;) I went back to 3.1.4, since I am testing on > > >> a live server (no other choice unfortunately.) > > >> > > >> I also tried writing a basic function that does nothing but > > >> display a session id, no other modules included and it gave the > > >> same results. You guys probably knew that was the case, but just > > >> an FYI. > > >> > > >> Thanks again, > > >> > > >> Peter > > >> > > >> On 10/11/05, Graham Dumpleton <grahamd at dscpl.com.au> wrote: Making > > >> an educated guess (???), in src/mod_python.c, can you modify the > > >> release_interpreter() function and change: > > >> > > >> static void release_interpreter(void) > > >> { > > >> PyThreadState *tstate = PyThreadState_Get(); > > >> #ifdef WITH_THREAD > > >> PyEval_ReleaseThread(tstate); > > >> #endif > > >> PyThreadState_Delete(tstate); > > >> } > > >> > > >> to: > > >> > > >> static void release_interpreter(void) > > >> { > > >> PyThreadState *tstate = PyThreadState_Get(); > > >> #ifdef WITH_THREAD > > >> PyEval_ReleaseThread(tstate); > > >> #else > > >> PyThreadState_Swap(NULL); > > >> #endif > > >> PyThreadState_Delete(tstate); > > >> } > > >> > > >> The original doesn't seem quite right to me because it wouldn't > > >> revert > > >> the thread state before deleting it when threads aren't used. > > >> There is a > > >> similar bit of code in get_interpreter() where it has: > > >> > > >> if (!idata->obcallback) > > >> { > > >> #ifdef WITH_THREAD > > >> PyEval_ReleaseThread(tstate); > > >> #endif PyThreadState_Delete(tstate); > > >> > > >> which perhaps should be: > > >> > > >> if (!idata->obcallback) > > >> { > > >> #ifdef WITH_THREAD > > >> PyEval_ReleaseThread(tstate); > > >> #else > > >> PyThreadState_Swap(NULL); > > >> #endif > > >> PyThreadState_Delete(tstate); > > >> > > >> In this case it only gets invoked when mod_python callback can't be > > >> created. > > >> > > >> If this is indeed the problem, in mod_python 3.1.3, the callback > > >> may be > > >> created okay so it only dies in release_interpreter(). In > > >> mod_python 3.2 > > >> though, maybe the callback creation itself is failing meaning it > > >> would > > >> die everytime a child process is created. > > >> > > >> If someone has the time and a non BSD platform could you > > >> independently > > >> build a version of Python without thread support and then build > > >> mod_python 3.2 and see if you get similar crashes. Ie., I feel this > > >> could be wrong for no threads and not be BSD specific. From what I > > >> have > > >> seen, FreeBSD is the only platform that still doesn't build in > > >> threads > > >> to Python by default and thus why it isn't seen more. I can't do it |