|
Graham Dumpleton
grahamd at dscpl.com.au
Fri Oct 14 22:58:59 EDT 2005
Python's rules for determining the default PYTHON_PATH are stupid. Even when loaded from inside of Apache as part of mod_python, it seems to search PATH for a "python" executable. If it finds one it will assume that that is the correct one and somehow base the PYTHON_PATH on that. I eliminated the "init" problem by simply ensuring that the version of Python I used to build mod_python was the first found in my path. As it was it was still finding the system default version of Python which had mod_python 3.1.4 installed. It therefore was loading mod_python modules from 3.1.4 and not 3.2.2 as installed in my separate copy of Python. Having sorted that out, then got to the next problem, which is a bug in mod_python.publisher (cache) when threading isn't built into Python. http://issues.apache.org/jira/browse/MODPYTHON-82 Fixed that. After that the resource I tried to access didn't actually exist so it tried to return 404. At that point Apache died because of: Fatal Python error: PyThreadState_Delete: tstate is still current [Fri Oct 14 22:50:21 2005] [notice] child pid 6150 exit signal Aborted (6) I then applied the thread state fix previously mentioned. Ie., #ifdef WITH_THREAD PyEval_ReleaseThread(tstate); #else PyThreadState_Swap(NULL); #endif and PyThreadState_Delete error disappeared and 404 was returned okay. Then accessed a real resource implemented using publisher and it sent back the actual result. In summary: 1. Make sure PATH will find the version of Python you used to build mod_python before any other version. 2. Apply fixes as described in: http://www.modpython.org/pipermail/mod_python/2005-October/019236.html 3. Fix mod_python.cache bug as described in: http://issues.apache.org/jira/browse/MODPYTHON-82 Then let us know if you still have problems. Graham On 15/10/2005, at 11:35 AM, Graham Dumpleton wrote: > Most strange. Good news is that have managed to get onto a Linux system > and build up non threaded Python and duplicate it. > > [Fri Oct 14 21:30:31 2005] [notice] Apache/2.0.55 (Unix) > mod_python/3.2.0b Python/2.3.5 configured -- resuming normal > operations[Fri Oct 14 21:30:32 2005] [error] make_obcallback: could > not call init.\n > TypeError: init() takes no arguments (2 given)Fatal Python error: > PyThreadState_Delete: tstate is still current > [Fri Oct 14 21:30:32 2005] [notice] child pid 609 exit signal Aborted > (6)[Fri Oct 14 21:30:43 2005] [error] make_obcallback: could not call > init.\n > TypeError: init() takes no arguments (2 given)Fatal Python error: > PyThreadState_Delete: tstate is still current > [Fri Oct 14 21:30:44 2005] [error] make_obcallback: could not call > init.\nTypeError: init() takes no arguments (2 given) > Fatal Python error: PyThreadState_Delete: tstate is still current[Fri > Oct 14 21:30:44 2005] [notice] child pid 610 exit signal Aborted (6) > [Fri Oct 14 21:30:44 2005] [notice] child pid 611 exit signal Aborted > (6) > > More later when I work out why it is happening. :-) > > Graham > > On 15/10/2005, at 4:24 AM, Peter Sanchez wrote: > >> Sorry for the late reply, got busy yesterday. >> >> I did as you suggested, and it errors when trying to start apache >> (unable to load mod_python.so), so it has to be the right module. >> >> So, now I put it back to the 3.1.4 version again, and I thought the >> entire pages were loading, but when I load pages with a lot more >> data, I realize that they aren't loading in whole. So I am still >> trying to figure out why it is crashing. >> >> Is there any way to trace the mod_python process, not sure if this >> would even help. >> >> Thanks guys, >> >> Peter >> >> On 10/12/05, Graham Dumpleton <grahamd at dscpl.com.au> wrote: >>> If it truly is picking up this file, it should fail to find it. If >>> not and >>> you still get the error, there must be another copy somewhere >>> which is being found. >>> >>> Sorry, if this seems like I don't trust what you say, but the error >>> really suggests that an old version is being used and this will at >>> least try and confirm whether your new one is being used or not. >>> >>> Other things to check are that there aren't two LoadModule lines in >>> Apache config file for mod_python.so where each grabs it from a >>> different location. A long shot would be that mod_python.so is >>> somehow statically compiled into Apache. >>> >>> Graham >>> >>> >>> Peter Sanchez wrote .. >>> > OK, I checked on the mod_python.so, the time stamp is the same as >>> the >>> > mod_python .py files in the python site-packages directory >>> (remember I >>> > just reinstalled them tonight) >>> > >>> > Also, if I do a 'strings mod_python.so | grep 3' I get >>> "mod_python/3.2.2" >>> > >>> > so I am assuming it is the correct one. >>> > >>> > Any other ideas? >>> > >>> > Thanks!! >>> > >>> > Peter >>> > >>> > On 10/12/05, Graham Dumpleton <grahamd at dscpl.com.au> wrote: >>> > > 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 >>> > > > > >> personally as have MacOS X and one has to be careful with >>> multiple >>> > > > > >> Python installations there in case one trashes system one >>> > > > > >> accidentally. >>> > > > > >> Would rather not risk it. :-) >>> > > > > >> >>> > > > > >> Graham >>> > > > > >> >>> > > > > >> Peter Sanchez wrote .. >>> > > > > >> > Thanks for the reference. I tried adding the following >>> line, >>> > no >>> > > > > >> real help. >>> > > > > >> > So I rebuilt apache2 and mod_python and made sure it >>> didn't >>> > have >>> > > > > >> threads >>> > > > > >> > support. Now, I still get the same error message, but >>> the entire >>> > > > > >> page is >>> > > > > >> > loading correctly? >>> > > > > >> > >>> > > > > >> > Same log entries though: >>> > > > > >> > >>> > > > > >> > Fatal Python error: PyThreadState_Delete: tstate is >>> still current >>> > > > > >> > [Tue Oct 11 13:05:15 2005] [notice] child pid 256 exit >>> signal >>> > > > > >> Abort trap >>> > > > > >> > (6) >>> > > > > >> > >>> > > > > >> > I am wondering if at this point, its not related to >>> Cheetah >>> > > > > >> Template engine, >>> > > > > >> > which I use for my templates (will be converting to psp >>> template >>> > > > > >> system >>> > > > > >> > very >>> > > > > >> > soon) I am not sure if that attempts any threaded >>> functions, >>> > > > > >> etc. Also, >>> > > > > >> > I >>> > > > > >> > dont know that if it was trying something like that, if >>> it would >>> > > > > >> effect >>> > > > > >> > mod_python in this way. >>> > > > > >> > >>> > > > > >> > Is there any traces I can run, etc. to help debug this >>> issue? >>> > > > > >> > >>> > > > > >> > Thanks, >>> > > > > >> > >>> > > > > >> > Peter >>> > > > > >> > >>> > > > > >> > On 10/11/05, Jim Gallacher < jg.lists at sympatico.ca> >>> wrote: >>> > > > > >> > > >>> > > > > >> > > Peter Sanchez wrote: >>> > > > > >> > > > OK, I tried 3.2.2b from source. Now, when I start >>> apache, >>> > > > > >> the logs >>> > > > > >> > just >>> > > > > >> > > > go into a loop with the same errors as before :) >>> > > > > >> > > > >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] Apache/2.0.54 >>> (FreeBSD) >>> > > > > >> PHP/4.4.0 >>> > > > > >> > > > mod_python/3.2.0b Python/2.4.1 configured -- >>> resuming normal >>> > > > > >> operations >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 26791 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 26318 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 26317 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 24178 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 24162 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 24148 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 24133 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 24122 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 24050 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 24033 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 23318 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 23285 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 23266 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 2005] [notice] child pid 23195 >>> exit >>> > > > > >> signal Abort >>> > > > > >> > > > trap (6) >>> > > > > >> > > > [Tue Oct 11 10:26:14 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 10:26:14 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 >>> > > > > >> > > > >>> > > > > >> > > > Note, these were being given while NOT loading my >>> mod_python >>> > > > > >> code, >>> > > > > >> > I >>> > > > > >> > > > think it was doing this for every 'normal' apache >>> instance. >>> > > > > >> I quickly >>> > > > > >> > > > reverted back to the last setup (mod_pyton/3.1.4) >>> > > > > >> > > > >>> > > > > >> > > > Any other ideas guys? >>> > > > > >> > > > >>> > > > > >> > > > Thanks, >>> > > > > >> > > > >>> > > > > >> > > > Peter >>> > > > > >> > > > >>> > > > > >> > > >>> > > > > >> > > This sounds like the problem I was having trying to >>> get the >>> > > > > >> 3.2.2b unit >>> > > > > >> > > tests to pass on FreeBSD. This was discussed on the >>> python-dev >>> > > > > >> list >>> > > > > >> > > around Sept 10. >>> > > > > >> > > >>> > > > > >> > > You can read the archive on gmane at >>> > > > > >> > > >>> http://comments.gmane.org/gmane.comp.apache.mod-python.devel/1465 >>> > > > > >> > > >>> > > > > >> > > Grisha suggested you can see this sort of problem on >>> FreeBSD >>> > > > > >> where >>> > > > > >> > > Python is threaded and Apache is not and offered the >>> following: >>> > > > > >> > > >>> > > > > >> > > If you built apache without thread support, you may >>> need to >>> > > > > >> add the >>> > > > > >> > > following lines to $PREFIX/sbin/envvars: >>> > > > > >> > > >>> > > > > >> > > LD_PRELOAD=/usr/lib/libc_r.so >>> > > > > >> > > export LD_PRELOAD >>> > > > > >> > > >>> > > > > >> > > Regards, >>> > > > > >> > > Jim >>> > > > > >> > > >>> > > > > >> >>> > > > > >> >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > _______________________________________________ >>> > > > > > 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
|