ID: 40479
Comment by: asilentpenguin at yahoo dot com
Reported By: rrossi at maggioli dot it
Status: No Feedback
Bug Type: Reproducible crash
Operating System: Suse Linux 9.0
PHP Version: 5.2.1
New Comment:
On Fedora / centOS
edit:
/usr/local/apache2/bin/apachectl
and add:
export USE_ZEND_ALLOC=0
and stop & start apache.
P.S.: i think you are underestimating the number of occurences for this
bug and, as so, the frustration amongst PHP developers
Previous Comments:
------------------------------------------------------------------------
[2009-07-30 06:22:49] laurynas dot butkus at gmail dot com
Finnally, found solution on Ubuntu Hardy.
Add line:
export USE_ZEND_ALLOC=0
to file:
/etc/apache2/envvars
and restart apache... Crashing stopped.
------------------------------------------------------------------------
[2009-06-24 23:31:17] ras...@php.net
This has turned into a catch-all bug report for any generic memory
corruption, not even necessarily in PHP itself. It could be a 3rd-party
library stomping on memory as shown by some of the reports of things
going away when upgrading a lib. As a single bug report it isn't of
much use to us, but the backtraces to help and might point us to an
actual problem in PHP.
------------------------------------------------------------------------
[2009-06-24 23:14:03] BAReFOOt at mailinator dot com
Well, I we mysql, the installed webapp (mediawiki) is not using it,
it's version 5.0.70, we got the debug extension enabled, and we still
get the bug.
It crashes the whole apache (2.2.11) instance! We don't have any
special PHP extensions on it.
But frankly, by knowing the quality of the Zend engine code itself, I
do not have any hopes that there is anyone who works on that code, and
is even remotely able to fix this. :P
I recommend switching to a real language, and stop using this
VisualBasic of web languages. :/
Sorry, after all this time, (255 days, or 8.5 months!), I have no good
words for this anymore. It basically makes PHP useless, and any new PHP
development (webapps), are now completely out of question in our
company.
------------------------------------------------------------------------
[2009-05-22 14:37:15] chris at crgs dot co dot uk
Hi,
Just to echo the previous comment, I have experienced the same crash
with PHP 5.2.9-2 under Win32 (Server 2003 R2), when upgrading the MySQL
DLLs from 5.0.77 to 5.1.34. I am bypassing the copy of libmysql.dll
provided with PHP in order to work around another bug, and I found that
when I upgraded to libmysql.dll 5.1.34, PHP crashed out with the
'zend_mm_heap corrupted' error when running certain scripts (especially
ones that access MySQL, like phpMyAdmin), which in turn caused IIS to
error out with 'CGI Error: The specified CGI application misbehaved by
not returning a complete set of HTTP headers.'
The issue is resolved if I copy libmysql.dll version 5.0.77 into my PHP
path, which indicates that this may be one of the causes of the
problem.
I can reproduce this bug reliably.
------------------------------------------------------------------------
[2009-04-29 17:30:49] jesse at eonstreet dot com
Hello,
I too have been able to recreate this bug with php 5.2.9
It occurrs when UPGRADING from Mysql 5.0.45 x64 el5 to Mysql 5.1.x x64
el5. (mysql 5.1.25 5.1.30 5.1.33 5.1.34
The error occurrs when I recompile PHP against the new Mysql-devel
5.1.x header files.
I've tried compiling against the native PHP mysql libraries and also
specifying the mysql libraries in /usr.
I believe that the heap error occurrs due to a debug necesity becuase I
followed the advice of a previous comment(THANK YOU!!!!) I placed
enable-debug in the configure command and IT WORKS!
I can't pin it down for sure but there is some incompatibility with
mysql 5.1.x and the php-mysql extension that calls a function from the
debug extension.
I think the solution lies in checking the mysql extension in PHP and
finding where the debug function is called and only calling with the
debug extension enabled / loaded.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40479
--
Edit this bug report at http://bugs.php.net/?id=40479&edit=1
