I can't confirm if this has solved the GeoDjango issue but I can say that the other issue is still present. Here's what I get (on any attempt, and any case) in the error log:
[Wed Jul 08 21:07:16 2009] [error] [client 207.97.208.143] Premature end of script headers: handler.wsgi [Wed Jul 08 21:07:16 2009] [error] [client 98.23.144.55] Premature end of script headers: handler.wsgi [Wed Jul 08 21:07:17 2009] [notice] child pid 21091 exit signal Segmentation fault (11) This is happening due to a MySQL warning (which I believe is called in __del__) so it pipes to stderr instead of a normal exception. Other than that I don't think there's anything unique about this case, but I've noticed it happening in other MySQL warning situations as well. ---- David Cramer On Wed, Jul 8, 2009 at 8:00 PM, Graham Dumpleton <[email protected] > wrote: > > 2009/7/9 David Cramer <[email protected]>: > > > > We are running the aptitude package (in Ubuntu) which says "Version: > > 2.3-1build1". As far as the global interpreter goes our config looks > > like this: > > > > WSGIScriptAlias / /home/ibegin/iplatform/handler.wsgi > > WSGIDaemonProcess www.ibegin.com display-name=ibegin.com > > processes=3 threads=10 stack-size=512kb deadlock-timeo$ > > WSGIProcessGroup www.ibegin.com > > > > I didn't quite understand in your post if you are suggested to add the > > global flag, or just leave the default. > > The default is actually: > > WSGIApplicationGroup %{RESOURCE} > > This in simple case of 80/443 ports, equates to a named sub > interpreter being used with name composed from: > > SERVER_NAME|SCRIPT_NAME > > That is, combination of name of virtual host and the mount point of > the WSGI application. > > Because it is a named sub interpreter, it is actually a Python sub > interpreter within the same process. > > So, what I want you to do is override this default and explicitly define: > > WSGIApplicationGroup %{GLOBAL} > > The value '%{GLOBAL}' effectively gets internally expanded to be empty > string, ie., '', which in mod_wsgi is used to refer to the main Python > interpreter. That is, the interpreter that was created when > Py_Initialize() was called. > > The main Python interpreter is special in as much as third party C > extension modules which use simplified GIL state API will only work > properly in Python main interpreter. There are also other things C > extension modules can do which will also cause them not to work in a > Python sub interpreter, but will still work in the Python main > interpreter. > > In delegating WSGI application to main Python interpreter within the > process, does mean that that should be only WSGI application delegated > to that daemon process group, unless you qualify use of > WSGIApplicationGroup within Directory or Location container to say it > only applies to a specific application delegated to that daemon > process group. > > Anyway, since it is moderately reproducible, just add: > > WSGIApplicationGroup %{GLOBAL} > > and see if you can still trigger it. That will at least answer > question of whether it helps. > > As I said before, my recollection is that when using GeoDjango that > you need to do this. > > Graham > > > If the bug which you are referring to only happens when a request is > > cancelled that wouldn't be our issue. Im personally reproducing these > > in the browser, and it's a full page load which ends up with a default > > Apache ISE page, and a useless message in the error.log (thus the > > reason this is such an issue for us, we're unable to debug anything we > > can't reproduce). > > > > On Jul 8, 7:37 pm, Graham Dumpleton <[email protected]> > > wrote: > >> 2009/7/9 David Cramer <[email protected]>: > >> > >> > >> > >> > >> > >> > We're having some issues with the dread seg faults. I've been going > >> > through the checklist and so far I'm not finding anything. > >> > >> > It happens in 2 specific areas right now: > >> > - MySQLdb throwing a warning. > >> > - Geodjango throwing an error in it's __del__ (sys.stderr). > >> > >> > I believe this may be entirely with __del__'s but I'm not sure how > >> > internals of MySQLdb work. I've confirmed expat and mysqldb are the > >> > same. We had no mysql db module for apache, but I'm guessing that's > >> > not abnormal. I've also confirmed that mod_python is uninstalled so > >> > there should be no conflicts from there. > >> > >> > The two specific things we see in apache are: > >> > >> > - [Mon Jul 06 10:10:57 2009] [error] [client 207.97.218.238] Premature > >> > end of script headers: handler.wsgi > >> > - [Mon Jul 06 10:10:57 2009] [notice] child pid 32555 exit signal > >> > Segmentation fault (11) > >> > >> Hi David, saw your posts on #django about white 500 pages. Been > >> meaning to drop you an email about it and see what it was about. > >> > >> A couple of questions. > >> > >> First, which version of mod_wsgi are you using? > >> > >> Second, are you using: > >> > >> WSGIApplicationGroup %{GLOBAL} > >> > >> to ensure that Django running in main interpreter inside of the daemon > >> process you are delegating it to? > >> > >> My understanding is that parts of GeoDjango, or things it uses, will > >> not work in Python sub interpreters and so necessary to force it to > >> run in Python main interpreter, which for mod_wsgi is don't use the > >> above WSGIApplicationGroup directive and setting it to '%{GLOBAL}'. > >> > >> There is also one known cause of a segmentation fault in daemon mode > >> with current 2.X release tar balls. It only happens in rare > >> circumstances as it is dependent on client closing connection at > >> specific point in between Apache accepting request and WSGI > >> application making first attempt to read request content. The patch > >> for this issue is: > >> > >> Index: mod_wsgi.c > >> =================================================================== > >> --- mod_wsgi.c (revision 1351) > >> +++ mod_wsgi.c (revision 1352) > >> @@ -1540,7 +1540,6 @@ > >> > >> if (n == -1) { > >> PyErr_SetString(PyExc_IOError, "request data read error"); > >> - Py_DECREF(result); > >> return NULL; > >> } > >> > >> In your case you seem to have associated problem with one of those > >> third party packages, so this latter problem may not be cause and may > >> be sub interpreter issue. > >> > >> Graham > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
