APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

PHP Segmentation Fault on Page Loads

© August 2009 Mike Hostetler
Mike Hostetler Web Site: https://squarepegsystems.com

A lot of people have problems with PHP the language, but I've never come into this problem before involving the Apache PHP module.

A long time customer got back in touch with me. A web app he's been working on was getting ready to go prime time and they ran a security audit on the server. That audit found several things wrong, and strongly recommended an upgrade to PHP 5.2.10. As of this writing, PHP 5.2.10 was very new and Debian testing didn't even have a package for it yet. So I fiddled around and finally found did the right combination of pinning to install PHP 5.2.10 from unstable. If you are thinking "Yikes!" then you are already ahead of me.

The next day, I get an email saying that their webapp just stops. I get on and, sure enough, sometimes, randomly, you get a blank page. Not a 404, 405, or another error -- just a blank white page. A reload and it works fine. I checked out /var/log/apache2/error.log and see tons of messages with the following:

[notice] child pid 24483 exit signal Segmentation fault (11)
[notice] child pid 24485 exit signal Segmentation fault (11)
[notice] child pid 24481 exit signal Segmentation fault (11)
[notice] child pid 24489 exit signal Segmentation fault (11)

Oh, that's bad. Playing around with it demonstrates that the seg fault happens when the page doesn't show up — just like I thought.

Now I get into detective mode and try to figure out what the heck is going on. I found DotDeb, which makes fresh Debian packages for older releases -- like PHP 5.2.10 for Debian testing! But the installers of that package was having the same problems I had. By careful reading, it seems that Debian installed at least part of the Suhosin security patch and that seems to be culprit. Users commented that disabling it seemed to stop the seg faults. But how do you do disable it?

I looked at the configurations in /etc/php5 and there was a file in conf.d called suhosin.ini, but no mention of it in the main apache2/php.ini file (the main PHP config for Apache2 in the Debian world). In a lark I moved suhosin.ini to suhosin.ini.bad and restarted Apache. And the problem when away. Like magic.

This is the problem when you are to use the versions. Because sometimes the latest isn't the greatest, and the documentation just can't keep up.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> PHP Segmentation Fault on Page Loads


Inexpensive and informative Apple related e-books:

Take Control of Pages

Take Control of Automating Your Mac

Take Control of iCloud, Fifth Edition

Take Control of Preview

Take Control of Apple Mail, Third Edition

More Articles by © Mike Hostetler

Sun Aug 30 15:44:54 2009: 6811   drag

For Debian a lot of times the better approach is to recompile newer packages for older distros rather then try to suck a newer binary package to a older system.

You can do that by adding deb-src lines in your /etc/apt/sources.list file that point to the newer release. Then you run:

apt-get update
apt-get build-dep $package-name

Were $package-name is the package you want to backport. Sometimes you'll run into issues were the package your trying to install requires newer libraries to compile against then what is available. In that case you just have to backport those, too...

Once you get the build dependencies satisfied you can go:

apt-get -b source $package-name

To fetch and build the source code into a deb package.

If you want to modify the package, like use different compile time options to enable or disable features or patch the source code you can use:
apt-get source $package-name

and that won't automatically build it. Then you can fiddle around with the files all you want before building it using the dpkg-buildpackage command.

Although going from Testing to Unstable and visa versa should not pose much of a problem. Testing and Unstable are essentially the same thing. Packages are built and ran in Unstable and are transfered directly to Testing once they have gone through some testing. Backporting is only really necessary when your trying to pull in Testing/Unstable packages into Stable and things like that.

And most popular packages are found in (link) That way if your using stable and need certain packages (like a newer kernel or PHP) then you can go there and have them pre-built for you.


I know that above would of not avoided your issue, but I'd like to point that out for people that want to run Stable, but may need newer versions of certain software.


For most people their security concerns could of been solved by making sure to use apt-get to subscribe to Debian security updates. It used to be that Debian security did not support Testing, but nowadays they do. Its hard to say from my end what the auditors did't like, but if there is a known security problem then it should be resolved relatively quickly by the security team.


Oh and I never liked PHP much. Nor did I like the idea of running a interpreter integrated into the web server.

Personally my current favorite way to do things is to run Python with WSGI protocol. That way you can keep things like a CGI almost, but instead of launching a new script each time you need it, Wsgi apps are long running and thus you don't get the same performance penalty. Plus you can chain WSGI apps to a certain extent and for smaller websites you can just use a Python-based webserver. Something like that. But I understand the need for PHP for a lot of people due to the application requirements.

Sun Aug 30 15:52:36 2009: 6812   TonyLawrence

I don't use any PHP here because of the many security problems that have happened over the years. Of course, most of those are specific scripts rather than the language itself, but still I just don't like it.

Sat Mar 2 11:03:45 2013: 11922   IliasK


Thank you for your suggestion on "PHP Segmentation Fault on Page Loads".
It worked for me on debian squeeze. Will I have some kind of security problems renaming suhosin.ini?

Sat Mar 2 11:17:14 2013: 11923   TonyLawrence


Well, suhosin is supposed to harden security so possibly, yes.


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

The three chief virtues of a programmer are: Laziness, Impatience and Hubris. (Larry Wall)

Linux posts

Troubleshooting posts

This post tagged:



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode