Page 1 of 1

PHP is segfaulting, what to do next?

Posted: Sun Mar 25, 2007 9:41 pm
by Ambush Commander
I am attempting to run a unit test suite on an external server, but PHP keeps segfaulting. I cannot reproduce it on my computer. The location of the segfault is consistently at the same spot, but makes no sense as to why. What to do now?

Posted: Sun Mar 25, 2007 11:07 pm
by wei
run each test separately to narrow it down...?

Posted: Sun Mar 25, 2007 11:34 pm
by infolock
Let me guess, it's part of a class that is causing the seg fault. and all you get is "An error has occurred. Please report this to support @ php.net" or something like that? or is this something completely different?

If it's what I just said, and it's php 4, I've run into a similar problem, but found no solution. The class would work fine on our corporate servers but when I pulled it locally it would bomb. Worse yet, it would only happen in gentoo linux, windows boxes would run fine. heh..

Posted: Mon Mar 26, 2007 2:19 pm
by Ambush Commander
run each test separately to narrow it down...?
That's the kicker: it segfaults in the initialization code, during a for() {} loop that is outputting <input> fields!
Let me guess, it's part of a class that is causing the seg fault. and all you get is "An error has occurred. Please report this to support @ php.net" or something like that? or is this something completely different?
Nope. It just stops executing. When I call via command line it actually says "Segfault, see core dump" via the error stream, but that's it.

Here's the link, if anyone's interested: http://hp.jpsband.org/live/tests/ and the source code: http://hp.jpsband.org/svnroot/htmlpurif ... /index.php

Posted: Tue Mar 27, 2007 6:23 pm
by Ambush Commander
Alright, I've sort of resolved the issue, although I'd like to know why it was happening/

The reason why it was erroring out in the "random" place was because "blocked" output buffering was on. Turning it off allowed me to pinpoint the problem code:

Code: Select all

$this->assertIdentical($output, $def->validate($input, $config, $context));
By unrolling it into:

Code: Select all

$result = $def->validate($input, $config, $context);
        $this->assertIdentical($output, $result);
Things started working again. There were three instances of this in the code, each consistently setting off the segfault. Other than that, everything was running fine.

Maybe Zend Optimizer causing the problem? Will investigate.

Posted: Tue Mar 27, 2007 7:39 pm
by Jenk
It's a zend engine thing.. in case you aren't aware - a segfault is when the application tries to write to memory that doesn't exist, or more specifically has not been allocated.

Perhaps the bug is when encompassing an object method call within an object method call like you have done.. I could see a recursion slip up (on the part of the php parser)

Posted: Tue Mar 27, 2007 8:03 pm
by Ambush Commander
Yeah, I'm vaguely aware of what segmentation faults are. Fixing them, however, is completely out of my league. I've never had to manage memory before, and I've never ever gotten a debugger to work.

I have strong evidence that Zend Optimizer 3.2.2 is at fault, as when I removed it from the php.ini, things started working, but adding it caused the segfault to happen again. Zend Optimizer 3.2.6 on Windows does not seem to have this problem, and I am currently installing 3.2.2 on my Windows box to test whether or not it's also a platform specific issue.

Edit: Nope, it's definitely Zend Optimizer 3.2.2. Crashes on my Windows box too! Not that this helps me, but I get a fuzzy feeling for knowing I'm not insane. O.o

Posted: Wed Mar 28, 2007 11:50 am
by RobertGonzalez
Do they have a bugtracker for things like this?

Posted: Wed Mar 28, 2007 3:24 pm
by Ambush Commander
It's already fixed, so there's really no point in reporting it. Otherwise, I would suppose: optimizer-bugs@zend.com