Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 161189 - php-eaccelerator 0.9.2a crashes with php5
Summary: php-eaccelerator 0.9.2a crashes with php5
Alias: None
Product: Fedora
Classification: Fedora
Component: php-eaccelerator
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Matthias Saou
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2005-06-21 08:23 UTC by Thomas M Steenholdt
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-06-30 13:59:58 UTC

Attachments (Terms of Use)

Description Thomas M Steenholdt 2005-06-21 08:23:24 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4

Description of problem:
using the mentioned version of eaccelerator with PHP 5.0.4 makes service content not work...

Updating to the latest version 0.9.3 solves any issues that i've seen!

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install php-eaccelerator-5.0.4_0.9.2a-2
2. restart httpd
3. try to load php pages from the server

Actual Results:  blank page (sorry, i've deleted my error logs for other reasons so i'm not sure if it logs a segfault or what)

Expected Results:  pages load at blazing speeds :-)

Additional info:

Comment 1 Matthias Saou 2005-06-21 08:58:51 UTC
I've started working on updating the package a few minutes before you opened
this bug :-) Expect 0.9.3 packages real soon now.

Comment 2 Thomas M Steenholdt 2005-06-25 16:32:23 UTC
I see the package and it does not crash as frequently as 0.9.2a, however
something appears to have gone wrong in packaging or something. On certain pages
it will get a crash like this :

======= Memory map: ========
[Sat Jun 25 18:24:04 2005] [notice] child pid 25785 exit signal Aborted (6)
*** buffer overflow detected ***: /usr/sbin/httpd terminated
======= Backtrace: =========
======= Memory map: ========
[Sat Jun 25 18:24:38 2005] [notice] child pid 25786 exit signal Aborted (6)
[Sat Jun 25 18:25:17 2005] [notice] caught SIGTERM, shutting down
[Sat Jun 25 18:25:18 2005] [notice] suEXEC mechanism enabled (wrapper:
[Sat Jun 25 18:25:19 2005] [notice] Digest: generating secret for digest
authentication ...
[Sat Jun 25 18:25:19 2005] [notice] Digest: done
[Sat Jun 25 18:25:19 2005] [notice] LDAP: Built with OpenLDAP LDAP SDK
[Sat Jun 25 18:25:19 2005] [notice] LDAP: SSL support unavailable
[Sat Jun 25 18:25:19 2005] [notice] mod_python: Creating 4 session mutexes based
on 256 max processes and 0 max threads.
[Sat Jun 25 18:25:20 2005] [notice] Apache configured -- resuming normal operations
[Sat Jun 25 18:25:52 2005] [notice] caught SIGTERM, shutting down
[Sat Jun 25 18:25:54 2005] [notice] suEXEC mechanism enabled (wrapper:
[Sat Jun 25 18:25:55 2005] [notice] Digest: generating secret for digest
authentication ...
[Sat Jun 25 18:25:55 2005] [notice] Digest: done
[Sat Jun 25 18:25:55 2005] [notice] LDAP: Built with OpenLDAP LDAP SDK
[Sat Jun 25 18:25:55 2005] [notice] LDAP: SSL support unavailable
[Sat Jun 25 18:25:55 2005] [notice] mod_python: Creating 4 session mutexes based
on 256 max processes and 0 max threads.
[Sat Jun 25 18:25:55 2005] [notice] Apache configured -- resuming normal operations

The really strange thing is that when i originally posted this bug, i made a
0.9.3 rpm from the 0.9.2a rpm specfile (just adjusted) and built it on my FC4
system. That package just works!

Very strange!

Didn't get a chance to look closely at the problem just yet, though!

Comment 3 Matthias Saou 2005-06-27 08:33:08 UTC
Strange indeed, as I don't do anything weird or special at build time, nor did I
change the default configuration.

I've opened a bug on the eaccelerator tracker :

Comment 4 Bart Vanbrabant 2005-06-27 09:26:27 UTC
The smpflags variable needs to be removed from the spec file. The rpm works fine
after that.

Comment 5 Matthias Saou 2005-06-27 09:47:32 UTC
Interesting. Then this is problably an upstream bug, as parallel make with -j2
and such shouldn't break the resulting files.

I'll remove the _smp_mflags for now. Thanks a lot Bart for spotting this, it
makes sense as the Fedora Extras build system sets _smp_mflags to -j2 or -j3 to
expose these kind of problems.

Comment 6 Bart Vanbrabant 2005-06-27 10:27:47 UTC
It doesn't fix it. Please look at the bug tracker of eAccelerator.
(zoeloelip == me)

Comment 7 Bart Vanbrabant 2005-06-27 12:16:53 UTC
A fix available in the eA bug tracker on sf. It was caused by a bufferoverflow.
The bug disappeared because it was a bug in the disk cache part and when a
working version was used the disk cache file was made. So the buggy part of the
code wasn't used anymore when testing the crashing version.

An other thing is that the configuration file should have these settings to:
eaccelerator.keys     = "shm_and_disk"
eaccelerator.sessions = "shm_and_disk"
eaccelerator.content  = "shm_and_disk"

It are the default values but otherwise users should get them from the example
configuration in the source tarball. 

Comment 8 Matthias Saou 2005-06-27 12:28:52 UTC
Thanks a lot for the patch!
Also, I'll add those default lines to the included .ini file. Note that the
example and well commented eaccelerator.ini from the sources is included in the
package's docs, so it's still easily available once the package is installed.

Comment 9 Thomas M Steenholdt 2005-06-27 12:51:42 UTC
That explains my initial 0.9.3 problem, since i had all except one of the pages
i tested, already cached. Strange thing though, is that removing all the cache
files and restarting httpd (thus reloading the php and included modules) doesn't
appear to automatically trigger the problem! So this what to be in "some
cases".. which of course is a very typical thing for a buffer overflow.

I'll build an updated local RPM (unless Matthias beats me to it) and try the
patched version out... Thanks a lot so far, guys!

Comment 10 Bart Vanbrabant 2005-06-27 13:03:44 UTC
The bufferowerflow always happened when a script cache file was writtin. It was
a really stupid thing. It copied the string "EACCELERATOR" to a char array char
string[8] in a struct. This string was the first field in the struct so the
other fields overwrite the overflow. This isn't a problem in this case but FC4
includes something that detects those overflows.
It wasn't really a bug, just some lazy programming of the previous maintainer.

(Matthias is there a way to notify the "extras" when there is a new release?)

Anyway I wouldn't mind helping out with eaccelerator bugs here. I'd rather not
maintain the package or something like that. Because for one package the whole
cvs/buildsystem stuff. Maybe it's possible to add me to the cc list when a bug
is filed for php-eaccelerator.

Comment 11 Thomas M Steenholdt 2005-06-28 11:27:29 UTC
I haven't seen any problems since installing a version with the buffer overflow
fix installed.
As far as i'm concerned, this bug can be closed, but i'll leave it open to give
Matthias a chance to react to Barts questions (in whatever way).

Matthias, please close the bug as you see fit!

Thanks again!

Comment 12 Matthias Saou 2005-06-28 14:15:30 UTC
Great! I'll close the bug entry once the package will have made it into the
public Extras tree.

Regarding notifications of new versions, I've now subscribed to the freshmeat
project entry, so as long as they're announced over there, I'll receive a prompt

Of course, if there are important changes (binary incompatibility, changes that
affect packaging), don't hesitate to contact me directly.

Last, if you go through the process of becoming a Fedora Extras package
maintainer, I wouldn't mind passing over the maintainership of that package,
especially since you seem to develop primarily on Fedora Core and are part of
the main eAccelerator developers.

Comment 13 Bart Vanbrabant 2005-06-28 17:08:24 UTC
Ok thanks. Because of whole the process of becoming a package maintainer, I
would rather not do that for just one package. You're doing a good job.
It would be good that I would be added to the cc list of this module. Because
you'll end up with me by filing the bug in the sourceforge tracker. When I'm on
the cc list I can directly react here and you will have less overhead. At the
moment I'm the only active developer/bug handler of eAccelerator anyway and I'm
a fedora user.

Comment 14 Matthias Saou 2005-06-30 13:59:58 UTC
I'm not sure if someone can automatically be added in CC for a given
component... but I'll definitely remember to manually CC you when I get bugs
opened regarding eAccelerator.

I'm closing this bug for now, since the original problem is now fixed. But I'm
still getting segfaults on some servers regarding another issue apparently. It's
being investigated and reported upstream.

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