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. 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. 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. Graham >> If all the process is then doing is subsequent exec then it is >> generally not a problem. It is when it wants to do mored complicate >> stuff that it becomes an issue. So to blanket say it is a really bad >> idea is plain wrong. > > > Yes, but this is not a C program, this is a Python program. Unless the > subprocess module is re-coded in C, it is not possible to call exec > immediately after fork. After calling fork from Python, control is > necessarily returned to the Python interpreter. > > 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.
