The only way to reproduce it is going to be wrote a C program which embeds Python and manually initialises Python via C API and then creates sub interpreter, manages sub interpreter thread states correctly and then executes problem code in the context of that. It isn't straight forward thing that most would be able to do. Sub interpreters can be created from pure Python code so must use C code. Is that what you have done so far to replicate it standalone?
Graham On 9 October 2011 03:45, Ron Garret <[email protected]> wrote: > > 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. > > -- 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.
