Bug 161189

I've started working on updating the package a few minutes before you opened
this bug :-) Expect 0.9.3 packages real soon now.

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: =========
/lib/libc.so.6(__chk_fail+0x41)[0x434565]
/lib/libc.so.6(__strcpy_chk+0x3f)[0x433bf7]
/usr/lib/php/modules/eaccelerator.so[0x9451a5]
/usr/lib/php/modules/eaccelerator.so[0x949054]
/usr/lib/php/modules/eaccelerator.so(eaccelerator_compile_file+0x938)[0x9499c4]
/etc/httpd/modules/libphp5.so(zend_execute_scripts+0x20a)[0x9b94653]
/etc/httpd/modules/libphp5.so(php_execute_script+0x260)[0x9b59fd7]
/etc/httpd/modules/libphp5.so[0x9bd0012]
/usr/sbin/httpd(ap_run_handler+0x41)[0xa85f3c]
/usr/sbin/httpd(ap_invoke_handler+0x5d)[0xa862d7]
/usr/sbin/httpd(ap_process_request+0x172)[0xa82e11]
/usr/sbin/httpd[0xa7d693]
/usr/sbin/httpd(ap_run_process_connection+0x41)[0xa90afb]
/usr/sbin/httpd(ap_process_connection+0x51)[0xa90e30]
/usr/sbin/httpd[0xa83d9e]
/usr/sbin/httpd[0xa8405a]
/usr/sbin/httpd[0xa8412a]
/usr/sbin/httpd(ap_mpm_run+0x9d0)[0xa84b0b]
/usr/sbin/httpd(main+0x5cb)[0xa8b88e]
/lib/libc.so.6(__libc_start_main+0xc6)[0x36ade6]
/usr/sbin/httpd[0xa7d151]
======= 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:
/usr/sbin/suexec)
[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:
/usr/sbin/suexec)
[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!

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 sf.net tracker :
http://sourceforge.net/tracker/index.php?func=detail&aid=1228096&group_id=122249&atid=692864

The smpflags variable needs to be removed from the spec file. The rpm works fine
after that.

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.

It doesn't fix it. Please look at the bug tracker of eAccelerator.
(zoeloelip == me)

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. 

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.

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!

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.

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!

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
notification.

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.

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.

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.