[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: "double free or corruption" error using PHP on Fedora Core 3

On Sat, Jan 08, 2005 at 08:52:06PM +0000, Alex Greg wrote:
> Recently I migrated the front-end of our bulletin board (running
> phpBB, patched against the recently highlight vulnerability) to a pair
> of servers running Fedora Core 3. I compiled Apache 1.3.33 and PHP
> 4.3.10 from source.
> This morning, the servers slowed down to the point that they were
> almost completely unresponsive. After a while I managed to SSH into
> the machines and saw that the httpd processes had grown to 35MB each
> and were using up all the swap and RAM on the machines (they have 1GB
> RAM, 1GB swap). I then set MaxClients to 30 and restarted Apache, but
> the slowdown happened again:
> I then checked the error log and found this:
> *** glibc detected *** double free or corruption: 0x097ec7e8 ***
> This bulletin board application has been running fine for a month or
> so on a pair of Fedora Core 1 servers running PHP 4.3.9 (which I've
> recently upgraded to 4.3.10), and they didn't have the above problem.

I'd guess your software has had a problem all along which went
unnoticed with earlier versions of glibc, and that the glibc
distributed with FC3 is now detecting the problem and issuing the

>From the Fedora Core 3 release notes:

      The version of glibc provided with Fedora Core 3 performs
      additional internal sanity checks to prevent and detect data
      corruption as early as possible. By default, should corruption
      be detected, a message similar to the following will be displayed
      on standard error (or logged via syslog if stderr is not open):

      *** glibc detected *** double free or corruption: 0x0937d008 ***

      By default, the program that generated this error will also be
      killed; however, this (and whether or not an error message is
      generated) can be controlled via the MALLOC_CHECK_ environment
      variable. The following settings are supported:

            0 -- Do not generate an error message, and do not kill the program
            1 -- Generate an error message, but do not kill the program
            2 -- Do not generate an error message, but kill the program
            3 -- Generate an error message and kill the program


      If MALLOC_CHECK_ is explicitly set a value other than 0, this
      causes glibc to perform more tests that are more extensive than
      the default, and may impact performance.

      Should you have a program from a third party ISV that triggers
      these corruption checks and displays a message, you should
      file a defect report with the application's vendor, since this
      indicates a serious bug.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]