Last modified: 2010-05-15 15:42:43 UTC
System is FreeBSD 6.1-RELEASE with / PHP Version 5.2.0, Apache 2.2.3, Mysql 5.0.27 When zend_extension="eaccelerator.so" is enabled in the extensions.ini file for eAccelerator v0.9.5 the system will not return a successful installation or build the LocalSettings.php file. If the extension is disabled and httpd restarted everything is fine. If the extension is added back after the successful instalation it will show blank pages again. Httpd-error_log shows the following message when accessing a page; [notice] child pid 73496 exit signal Segmentation fault (11)
I also installed /usr/ports/devel/pecl-operator when extension=operator.so is enabled in the extensions.ini file the edit pages are blank, however the main page is visible. The similar seg fault is displayed in the error log.
This most likely indicates a bug in eaccelerator, or an incompatibility between it and the latest PHP.
Or a bug in MediaWiki considering two different php optimization extensions segfault the software?
There's http://eaccelerator.net/ticket/204 which I ran into recently when I moved my wiki to a different server with PHP 5.2.0. apache would segfault when using anything cached by eA and I'd get a blank page with nothing to show for it in the logs besides the segfault. I built revision 284 off eA's svn and it works for me. Dunno if this is the problem you're having, though.
No bug in MediaWiki could cause a segmentation fault because MediaWiki's code does not dereference pointers to memory. One arguable exception is that a deeply-recursive loop in PHP script code can smash PHP's stack and produce a segfault. This is however a failure in PHP, which should be capable of enforcing an appropriate limit and failing out gracefully. Of course it's always possible that some behavior of MediaWiki's is _triggering_ a bug in your other software, which you do not encounter when not running MediaWiki.
(In reply to comment #5) > No bug in MediaWiki could cause a segmentation fault because MediaWiki's code does not > dereference pointers to memory. > > One arguable exception is that a deeply-recursive loop in PHP script code can smash PHP's > stack and produce a segfault. This is however a failure in PHP, which should be capable of > enforcing an appropriate limit and failing out gracefully. > > Of course it's always possible that some behavior of MediaWiki's is _triggering_ a bug in your > other software, which you do not encounter when not running MediaWiki. > What a waste of time it was to read this, why does anyone not offer real advice as to what is causing the error, rather then feeling like their testicles have been shrunk with the need for long winded defences.
Personal attacks on the lead developer are a great way to get volunteers to give you free technical help for a product that's intended essentially for Wikimedia use only and is released to the public as an afterthought.
Hardly an attack, just voicing my opinion on the way "triggered" results are defended.
Shit, lads, someone's discovered the kill-switch we added. 'Cause we hate the kind of people who use eAccelerator, and we'd LOVE to give out advice that we don't think is correct. Grow up. There's a bug somewhere, and you've been advised that it's probably not a bug in our code. You've been asked to check that it's not a bug somewhere else in the chain, where one is more likely to occur. If you don't like the way we're responding, then find some other free software to use.
Try the latest SVN of eAccelerator, that's what I use now, solved an eAccel problem I had before (with eAccel 0.9.5), though not the same "empty page" bug, but it did solved the problem. As someone above already suggested, try the latest eAccel SVN. If that doesn't solve it, then the problem is somewhere else. I don't use FreeBSD, but I can attest that it isn't with MediaWiki. I am running PHP5.2, mySQL5.0.7, MediaWiki 1.9.1, eAccel svn282 (the latest is 287), with Zend as well. Hope that helps.
*** This bug has been marked as a duplicate of 8990 ***
