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
> dereference pointers to memory.
> One arguable exception is that a deeply-recursive loop in PHP script code can
> 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
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 ***