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_Crashes_With_GDB 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 >> > 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 -~----------~----~----~----~------~----~------~--~---
