On Oct 7, 2011, at 11:21 PM, Graham Dumpleton wrote:
> On 8 October 2011 17:06, Ron Garret <[email protected]> wrote:
>>
>> On Oct 7, 2011, at 8:45 PM, Graham Dumpleton wrote:
>>
>>> Hmmm, the local setup I thought I was getting this issue on, I am not,
>>> The error on my local setup was:
>>>
>>> [Fri Sep 23 15:05:13 2011] [notice] child pid 97541 exit signal Abort trap
>>> (6)
>>> Fatal Python error: XXX block stack underflow
>>>
>>> So, something entirely different.
>>>
>>> If you can distill that test case down to exclude subprocess it would
>>> thus help because if it is anything would suspect subprocess doing
>>> something.
>>
>> I can reliably reproduce the problem thusly:
>>
>> pid = os.fork()
>> if pid:
>> sys.stderr.write('Fork succeeded (PID=%s)\n' % pid)
>> return ['OK - ', pid]
>> else:
>> sys.stderr.write('Fork succeeded (child PID=%s)\n' % os.getpid())
>> os._exit(0)
>>
>> Here's a small excerpt from my error log, the result of reloading the page
>> four times:
>>
>> [Fri Oct 07 08:15:15 2011] [error] Fork succeeded (PID=90595)
>> [Fri Oct 07 08:15:15 2011] [error] Fork succeeded (child PID=90595)
>> [Fri Oct 07 08:15:35 2011] [error] Fork succeeded (PID=90599)
>> Fatal Python error: Couldn't create autoTLSkey mapping
>> [Fri Oct 07 08:15:43 2011] [error] Fork succeeded (PID=90600)
>> [Fri Oct 07 08:15:43 2011] [error] Fork succeeded (child PID=90600)
>> [Fri Oct 07 08:15:45 2011] [error] Fork succeeded (PID=90601)
>> Fatal Python error: Couldn't create autoTLSkey mapping
>>
>>> If you aren't already, try adding:
>>>
>>> WSGIApplicationGroup %{GLOBAL}
>>>
>>> into Apache configuration just for that WSGI application.
>>
>> That made the problem go away.
>>
>>> This issue if there is one is likely going to relate to subprocess and
>>> forking in sub interpreters.
>>
>> I'm pretty sure the error is being generated by this code in pystate.py:
>>
>> /* Reset the TLS key - called by PyOS_AfterFork.
>> * This should not be necessary, but some - buggy - pthread implementations
>> * don't flush TLS on fork, see issue #10517.
>> */
>> void
>> _PyGILState_Reinit(void)
>> {
>> PyThreadState *tstate = PyGILState_GetThisThreadState();
>> PyThread_delete_key(autoTLSkey);
>> if ((autoTLSkey = PyThread_create_key()) == -1)
>> Py_FatalError("Could not allocate TLS entry");
>>
>> /* re-associate the current thread state with the new key */
>> if (PyThread_set_key_value(autoTLSkey, (void *)tstate) < 0)
>> Py_FatalError("Couldn't create autoTLSkey mapping");
>> }
>
> This code doesn't exist in Python 2.7.1 code that I have on my box.
It was apparently introduced in 2.7.2.
> This must be a new change and whatever they are doing has broken
> things for a fork done from a sub interpreter. So,could be a bug in
> Python.
I tried reproducing the problem standalone but was unable to. It seems like it
must be something mod_wsgi is doing because of the intermittent
reproducibility. Also the fact that WSGIApplicationGroup %{GLOBAL} makes the
problem go away is a pretty big clue.
For the record, I had WSGIApplicationGroup set to the name of my
WSGIDaemonProcess. I have half a dozen WSGI applications running on the same
machine. Each one has its own named WSGIDaemonProcess and a corresponding
WSGIApplicationGroup set to the same name. But I don't actually understand
what WSGIApplicationGroup is supposed to do, so this whole thing could be a
configuration error on my part.
> Querying the bug report for original issue and whether they checked
> fix for sub interpreters. Often they don't bother.
>
> Will do standalone test when get chance.
Thanks.
rg
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
