On 9 October 2011 12:08, Graham Dumpleton <[email protected]> wrote: > 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.
Sub interpreters can not be created .... > 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.
