[mod_python] PyThreadState_Delete: tstate is still current

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




More information about the Mod_python mailing list