Last modified: 2010-05-15 15:42:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8029 - Installation returns blank screen with eaccelerator-0.9.5 enabled
Installation returns blank screen with eaccelerator-0.9.5 enabled
Status: RESOLVED DUPLICATE of bug 8990
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.8.x
Other FreeBSD
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-24 18:03 UTC by bdash
Modified: 2010-05-15 15:42 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description bdash 2006-11-24 18:03:17 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)
Comment 1 bdash 2006-11-24 18:17:48 UTC
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.
Comment 2 Brion Vibber 2006-11-24 22:16:06 UTC
This most likely indicates a bug in eaccelerator, or an incompatibility between it and 
the latest PHP.
Comment 3 bdash 2006-11-25 03:10:41 UTC
Or a bug in MediaWiki considering two different php optimization extensions
segfault the software?
Comment 4 Fyren 2006-11-25 04:16:38 UTC
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.
Comment 5 Brion Vibber 2006-11-29 22:46:38 UTC
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.
Comment 6 bdash 2006-12-08 04:19:21 UTC
(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.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-08 04:25:55 UTC
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.
Comment 8 bdash 2006-12-08 04:37:11 UTC
Hardly an attack, just voicing my opinion on the way "triggered" results are
defended.
Comment 9 Rob Church 2006-12-08 21:29:08 UTC
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.
Comment 10 JC John SESE Cuneta 2007-02-05 07:28:08 UTC
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.
Comment 11 Brion Vibber 2007-02-15 07:39:27 UTC

*** This bug has been marked as a duplicate of 8990 ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links