php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #36862 *** glibc detected *** double free or corruption
Submitted: 2006-03-26 12:19 UTC Modified: 2006-04-03 01:00 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: nick at sterlingintegrated dot com Assigned:
Status: No Feedback Package: MySQL related
PHP Version: 5.1.2 OS: Fedora Core 3 (FC3)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
33 - 7 = ?
Subscribe to this entry?

 
 [2006-03-26 12:19 UTC] nick at sterlingintegrated dot com
Description:
------------
After an upgrade of MySQL from 3.23 to 4.0, I kept getting "mysql_connect not a valid function call". So I recompiled php.


Then I got a blank scrren on the browser. When run, "~php ./test.php" produces an error message (which can't be seen in the browser). The solution for me was to "export MALLOC_CHECK=0;" on the command line, so glibc stops going crazy then restart httpd. I set this env variable in my .bash_profile. It seems to work fine so far.

Reproduce code:
---------------
<?php
error_reporting(E_ALL);

$link = mysql_connect('localhost', 'user', 'password');
if (!$link) {
   die('Could not connect: ' . mysql_error());
}
echo 'Connected successfully';
mysql_close($link);
?>

Expected result:
----------------
Connected successfully

Actual result:
--------------
*** glibc detected *** double free or corruption

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-03-26 12:36 UTC] tony2001@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.


 [2006-04-03 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2006-04-13 06:29 UTC] israel at ochosting dot com
I had this problem on something similar, It had to do i believe something with Zend Optimizer, and an extension to Zend Optimizer (eAccelerator).  A Recompile of the same version of PHP without the Zend and the Extension allowed our affected pages to work.

I dont have the core dump files.  But this may help someone else get on the right track.

(PS.. Cpanel/WHM Box, Apache 1.3x, and PHP 4.4.1)
 [2006-05-23 03:35 UTC] dmobley at uhostme dot net
Oh my God, I have been chasing this same error for days!  I did almost the same thing, creating the test php page, etc. and MySQL/PHP kept popping errors in the error log about glibc detected.

I ssh'ed to the server, did "export MALLOC_CHECK_=0" and when I would run the php file from the command line, the error stopped.  However, I then restarted httpd and the problem in the browser was still there.  Is it not using the same environment variables that the ssh session is using or is it only apply to the root user and not apache?

I guess what I need to do is recompile PHP without the Zend optimizer.  Can someone please explain how I recompile PHP without the Zend optimizer?
 [2006-05-23 04:57 UTC] israel at ochosting dot com
Note from Googling...

http://www.redhat.com/archives/rhl-list/2005-January/msg01918.html
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 23 19:01:31 2024 UTC