First off, I ran into some issues early on in the project that were attributable to CakePHP’s caching mechanism. Not sure why though, because caching was off by default (in fact, I was only even vaguely aware of its existence) on the first project I did; this one is building on that one; and I didn’t change any settings for caching in the
core.php configuration file.
Caching is nice in a production environment, but it is a pain in the butt, to say the least, in a development environment. At least now I have it turned off. One less thing to worry about.
Today I’ve been struggling with some other frustrations that have nothing, really, to do with what I’m working on. What I’m working on would be frustrating enough, trying to wrap my brain around the intricacies of
hasAndBelongsToMany relationships. But I can’t even get to that because of a pair of other issues.
First up, something I think I’ve finally got figured out. I’m writing my admin tool right now, so all of the pages I’m working on are using admin routing. Again, it should just be working; this is building upon stuff I already wrote for the first big project, which is working great and has been live for over a month now. And, for the most part, the admin routing has been working, but every once in a while I’ll click on a page that tries to load in the default template, and when it does, I get this:
Fine, I can handle that. But when I was clicking on some pages that should be working, they just wouldn’t load, triggering the browser’s “server unavailable” error page, which I recognized as being the result of a segmentation fault error in Apache. So what within my PHP code, or in CakePHP, is crashing Apache? That was my real problem, and the reason for this blog post.
I googled “segmentation fault PHP” and got my answer in the form of the following:
Thank you very much! This problem is happening for me in my local development environment, running MAMP. So I dug into MAMP’s
php.ini file, and sure enough, Zend Optimizer was configured. I commented out all of the pertinent lines, bounced Apache, and we’re in business!
Well, sort of. The page still isn’t working, of course. It’s just now that its not working is not causing Zend Optimizer to crash Apache. Fortunately, I can see CakePHP’s error messages now, and it looks like I’ve got some problems in my model that are generating MySQL errors. Fair enough. At least I know what’s wrong now and can do something about it!
This is not a rant against CakePHP. Its error messaging is generally very useful, and its stack trace functionality rocks. Most of the time. Unfortunately it was a dangerous confluence of unrelated issues in my application today that caused the system to break down. But ultimately it was the result of issues with Zend Optimizer. I’m extremely thankful to “One Insightful M*******cker” for saving my sanity, and I just wanted to return the favor with a link back.