Quickie – Weird PHP Seg Faults & Custom Session Handlers

So, I have to say that I’m no server admin, but I certainly can accomplish most everything I need to do. Today I was working on setting up php on a production server to fit some unique needs, and ran into an interesting problem. The only unique thing about this setup is that mysql is installed in a non-standard way (two instances running on the same box so we can have replication), and basically all that was weird about this was the path to the mysql binaries and support files. So, what went wrong anyway?

Well, I got everything set up, and did my first test promotion from the production environment. I hit the site, and… nothing. Not an error message, just a white, useless screen. First thing I checked was that my show_errors directive was set to on, and it was, so no luck. The next step was to restart apache and check for any errors… again, nothing. Starting to get a little frustrated, I took a peek at my error logs (/var/log/httpd/error_log for the unitiated), and discovered a wonderful message:

[notice] child pid 32222 exit signal Segmentation fault (11)

As any person scratching their head would do, I hit up google… to no real avail. Just a bunch of php bug reports. So, what happened, and how did I fix it? Read on…

So, I did a bunch of bug tracing in my code and narrowed it down to a custom session handler I wrote. When I turned off the custom session handler, lo and behold, the site starts working! So I spend an hour trying to figure out what the hell was wrong with my code. Turns out, nothing… another waste of time to find out I was going in the wrong direction. Turns out the real problem went all the way back to when I compiled php. I hadn’t told php about my custom mysql setup, more specifically where it was! Normally, it never would have been a problem, as all the mysql functionality was working for the better part of my code. However, since I’d written a custom session handler, I was writing code that got a little closer to the php core. Since I was handling sessions in the database, the problem reared its ugly head.

Now this isn’t a php bug, it’s a complete result of human error. In a typical php compile, you will have the following somewhere in the config statement:

--with-mysql

99% of the time this is just fine. However, in my situation, mysql is in a non-standard location. So, if you’re like me, you’ll need to tell php where the mysql binaries and libraries are:

--with-mysql=[/path/to/mysql]

You may also need to tell php where the default socket is:

--with-mysql-sock=[/path/to/mysql/data/mysql.sock]

If none of the above means anything to you, you probably haven’t customized your php/mysql installation, and I would imagine that what I’ve outlined here doesn’t apply to you. Otherwise, hopefully you haven’t made this silly oversight, but if you have, this could be a solution to your problem! Like I said, the chances of this happening to anyone are slim to none, but I wanted to throw this out there to help anyone else out trying to do some serious php Kung Fu! Until next time…