[mod_python] Mod_python quit working

Monsyne Dragon mdragon at rackspace.com
Wed Jan 12 20:31:54 EST 2005

Graham Dumpleton wrote:

>Lets be realistic here. If there were hardware issues it is likely to manifest
>randomly and not be repeatable and more than likely the operating system
>as a whole would have crashed somewhat earlier than this point.
Not really.  Such hardware glitches can manifest in exactly this way.
The canonocal example of this is a linux system which seems to work 
fine, but cannot recompile the linux kernel because gcc always dies w/ a 
(I've actually seen this, and the problem was a dying CPU fan.  
Increased CPU load caused it to overheat (but only when loaded), and the 
gcc processes became  nice fat
targets for the resultant menory glitches because of the amount,  and 
way, gcc uses memory.  To crash the OS, the sporadic glitch would have 
to hit a kernel mem structure, which is
a smaller target. )  Typically,  if this sort of thing is due to a 
hardware glitch, its due to bad memory, or overheating. Either one can 
cause sporadic memory corruption,  and if that
garbles a pointer,  then you will often get a segfault when something 
tries to dereference it.

The one BIG caveat that I must add to this, tho, is that a hardware 
glitch should only be a main suspect _IF_ (and only if) what the 
origional poster said about the situation, is true, namely that this is 
a box that has been previously working for some time, and NOTHING,  I 
mean _NOTHING_ was changed on it software-wise.  (and the usual 
suspects, like diskspace, etc, have been eliminated.)

>I really don't get this blaming the hardware thing. This is the second time
>I have seen this recently given as a solution to a segmentation fault problem.
>This isn't helpful. Do you not understand what causes segmentation faults
>in the first place?
Erm, yes, I do understand segfaults quite well.   The reason it is 
mentioned in this context is that this sort of thing is not uncommon, 
especially on cheaper hardware, which, today, is most of it.

>Sorry, I just had to say this and if my day was going any worse I wouldn't
>have been so polite about it. :-)
Politeness is good :>  It tends to have a way of keeping days from 
getting worse, when they are not going good.
(Message brought to you by my mom, font of all wisdom since 1967 :> )

>Now, can we go backwards on this a bit and try and debug this in a more
>sensible way.
>First off, everything was supposedly working okay and then it started
>having this problem. Restarts of Apache didn't appear to fix anything.
>Even returning a simple string didn't appear to work.
>I am making an assumption here that the simple string was being returned
>from a mod_python handler. Instead of worrying about that for the moment,
>can the original poster answer the following questions.
>1. Does a normal static web page served up from a directory nothing to
>do with the mod_python area work? If it does, then Apache itself isn't
>necessarily stuffed.
>2. How have you set up your httpd.conf/htaccess file to enable use of
>mod_python in the directory you are accessing and is causing the problem?
>Post the actual directives you put in the config file here otherwise we
>would be guessing. Let us work out if you are doing anything strange.
>3. If you comment out all your existing config file entries for enabling
>mod_python in that directory (or any directories for that matter) and go
>back to square one and in a new directory, setup a bog standard mptest.py
>example as per mod_python documentation, does it work? Ie., take out
>of the picture any of your own personalised handlers.
>Once you have done that and if you can get a simple mptest.py working
>in clean area, then looking at your particular code at what dependencies
>it has would be appropriate.
>Overall, segmentation faults in mod_python are more likely to be caused
>by Apache, mod_python and Python being built with differing ideas of
>how threading is supposed to be enabled. Another possibility is that
>differing Apache extension modules have been built against different
>versions of shared libraries. A good example where this often happens is
>the expat library, since it can be loded by Python code running under
>mod_python and PHP code running in the same Apache process. If a
>different version of expat is used, something might crash if data layouts
>are different.
>Anyway, if the original poster can try and answer the above you might
>perhaps get some more useful feedback.
Good suggestions too.

-- M. Dragon

More information about the Mod_python mailing list