> On Mon, Jan 23, 2012 at 3:09 AM, Roberto De Ioris <[email protected]> > wrote: >> >> Il giorno 23/gen/2012, alle ore 09:54, C Anthony Risinger ha scritto: >> >>> On Sun, Jan 22, 2012 at 7:16 PM, C Anthony Risinger <[email protected]> >>> wrote: >>>> On Sun, Jan 22, 2012 at 2:18 PM, C Anthony Risinger <[email protected]> >>>> wrote: >>>>> >>>>> however, i am now getting a SIGSEGV on normal SIGINT while at the >>>>> --pyshell prompt: >>>> >>>> if i change plugins/python/python_plugin.c:201-202 from: >>>> >>>> Â Â if (uwsgi.has_threads) >>>> Â Â Â Â PyGILState_Ensure(); >>>> >>>> ... to: >>>> >>>> Â Â //if (uwsgi.has_threads) >>>> Â Â Â Â PyGILState_Ensure(); >>>> >>>> ... python 3.2.2 and 2.7.2 no longer segfault (my terminal is still >>>> messed up and requires a `reset`, but this is a different bug that has >>>> always existed). >>> >>> after grepping the source and poking around a bit, i see the ini files >>> in buildconf use: >>> >>> threading = 1 >>> >>> ... but the option is defined as: >>> >>> enable-threads >>> threads-* >>> >>> ... i dont see anywhere in the C code that uses the `threading` as a >>> configuration option ... should these be changed? >> >> The options in build profiles are only parse by uwsgiconfig.py > > yeah ... i remembered that about 10 seconds after "Send". > >> By the way, have you tried latest tip ? >> >> I have added a check for python availability (as pyshell will destroy >> the python environment on exit) in "atexit" hook > > yeah the comments i made were regarding the current tip at the moment > i sent, and i just tried again with the same segfaulting result. > > when stepping the code, Py_IsInitialized() does return true, but deep > within python routines threadstate_getframe receives (and tries to > dereference) a null pointer. > > it's like python is using threads anyway? once i comment out the check > for `uwsgi.has_threads` in `uwsgi_python_atexit`, and thus > unconditionally call `PyGILState_Ensure()`, everything works fine, but > i don't know enough to understand why completely. > > ... i tried that solution after reading this thread: >
This is pretty strange, it looks like the python interactive shell (--pyshell) is not fully releasing python, but freeing resources in some way. Maybe it would be easier to remove "atexit" handler if the worker has been hijacked. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
