After attempting to debug it with GDB/PDB I finally gave up. I failed to find ANYTHING at all, and decided to run an svn up on Django. Bugs gone, at least for now ;)
On Jul 8, 8:23 pm, Graham Dumpleton <[email protected]> wrote: > 2009/7/9 David Cramer <[email protected]>: > > > 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) > > Going backwards a bit and explain this, not just to confirm your > understanding, but so anyone else who sees this on the list in the > future understands. > > The error message 'Premature end of script headers' would normally > only ever happen when the mod_wsgi daemon process handling the request > crashes. The error message is actually being generated from the Apache > server child process which is proxying the request to the mod_wsgi > daemon process. The 'Segmentation fault' message is then from memory > generated by the Apache parent process when it detects that a child > process it is managing has crashed. If core files are being produced, > and because of how Apache parent detects child processes that have > vanished, this message may not a small amount of time to appear in > logs. > > > 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. > > Not that it matters, mod_wsgi will replace sys.stderr in Python > interpreter context such that stuff goes to Apache error log through > normal Apache logging APIs, such that date time stamps etc are added. > If MySQL is accessing C level stderr directly, it still goes to the > Apache error log, however, because of how Apache redirects stderr, it > is buffered and so if MySQL isn't flushing the error explicitly, any > message it logs that way may not turn up immediately. > > > 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. > > Only other thing I can suggest that this point since it is > reproducible by you, is to configure with a single daemon process and > attach GDB to that process and try and capture stack trace for me to > look at. For how to do that, see: > > http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Debugging_C... > > If you can do that, I'll have a think about it and see what else I can > suggest. > > Graham > > > ---- > > 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 > >> > WSGIDaemonProcesswww.ibegin.comdisplay-name=ibegin.com > >> > processes=3 threads=10 stack-size=512kb deadlock-timeo$ > >> > WSGIProcessGroupwww.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 -~----------~----~----~----~------~----~------~--~---
