|
|
Posted by Alex Greg on 01/10/05 13:08
On Mon, 10 Jan 2005 06:58:21 +0600, Raditha Dissanayake
<jabber@raditha.com> wrote:
> Alex Greg wrote:
>
> >(apologies if this reaches the list twice - the first time I sent it,
> >it didn't arrive within 12 hours)
> >
> >Hi,
> >
> >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. The MySQL database is running on a separate machine.
> >
> >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 ***
> >
> >
> Quite curiously I had this same problem just yesterday and spent quite a
> bit of time scratching around trying to get it to work again. I upgraded
> all of apache, glibc and php to know avail. Though this error had been
> seen many times before by others i found nothing relevent in google. In
> my case however it turned out to be a really trivial and stupid mistake:
> I had AddModule lines for the both the PHP4 and PHP5 SO in my httpd.conf
> file. Please check your own httpd.conf file. If not that it could also
> be conflicting extensions.
On Mon, 10 Jan 2005 06:58:21 +0600, Raditha Dissanayake
<jabber@raditha.com> wrote:
> Alex Greg wrote:
>
> >(apologies if this reaches the list twice - the first time I sent it,
> >it didn't arrive within 12 hours)
> >
> >Hi,
> >
> >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. The MySQL database is running on a separate machine.
> >
> >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 ***
> >
> >
> Quite curiously I had this same problem just yesterday and spent quite a
> bit of time scratching around trying to get it to work again. I upgraded
> all of apache, glibc and php to know avail. Though this error had been
> seen many times before by others i found nothing relevent in google. In
> my case however it turned out to be a really trivial and stupid mistake:
> I had AddModule lines for the both the PHP4 and PHP5 SO in my httpd.conf
> file. Please check your own httpd.conf file. If not that it could also
> be conflicting extensions.
Hi,
I've checked our httpd.conf files, and we're only loading PHP once:
LoadModule php4_module libexec/libphp4.so
....
AddModule mod_php4.c
Additionally, does anyone know why the httpd processes are growing so
big? This is common under mod_perl as it caches compiled code in
memory, but PHP doesn't do this so I've no idea why the httpd
processes are in the region of 35MB each. The only application we're
running on these servers is phpBB. Possibly PHP is leaking memory?
The reason why we didn't see this on our Fedora Core 1 servers is
because the glibc on Fedora Core 3 reports these corruptions (whereas
FC1's glibc doesn't). However, we do still see the 35MB httpd
processes on Fedora Core 1. From the FC3 release notes:
glibc
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
Note
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.
Any further advice would be greatly appreciated.
Regards,
-- Alex
Navigation:
[Reply to this message]
|