php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #20665 Memory leaks on SIGHUP
Submitted: 2002-11-26 19:47 UTC Modified: 2003-01-03 13:18 UTC
From: msopacua@php.net Assigned:
Status: Wont fix Package: Apache related
PHP Version: 4.3.0RC1 OS: BSD/OS 4.2
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: msopacua@php.net
New email:
PHP Version: OS:

 

 [2002-11-26 19:47 UTC] msopacua@php.net 
Running 4.3RC1 in production, I see a returning problem, for the allocation of 129 bytes. Since no executed file is being reported it's hard for me to track down which is the cause.

Additionally, on logrotation and a SIGHUP, there are leaks being reported, broken down to:
/home/mdev/_src/php-4.3.0RC1/Zend/zend_opcode.c(295) :  Freeing 0x082F6024 (7200 bytes)

Zend/zend_language_scanner.c(4365) :  Freeing 0x082E2824 (50 bytes)
Last leak repeated 112 times

Zend/zend_language_scanner.c(4450) :  Freeing 0x082DFAE4 (4 bytes)Last leak repeated 2 times
/home/mdev/_src/php-4.3.0RC1/Zend/zend_hash.c(262) :  Freeing 0x082DE324 (100 bytes)
Last leak repeated 76 times

Zend/zend_language_scanner.c(3060) :  Freeing 0x082E01A4 (84 bytes)
/home/mdev/_src/php-4.3.0RC1/Zend/zend_execute.c(478) :  Freeing 0x082DF7A4 (12 bytes)
/home/mdev/_src/php-4.3.0RC1/Zend/zend_hash.c(406) :  Freeing 0x082E2124 (35 bytes)
etc.

Full log here:
http://melvyn.idg.nl/php43/leaks.log

I stripped the script= part as it doesn't make any sence.

Note that this is the only point where these leaks are reported.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-11-26 20:19 UTC] sniper@php.net 
Was this with Apache? Please reclassify if so.
This is NOT "Performance problem"..
 [2002-11-27 03:05 UTC] msopacua@php.net 
Yep apache.
 [2002-11-27 17:03 UTC] iliaa@php.net 
The code that reports memory leaks also outputs PHP script name where the leak had occured. I am not sure if this was part of the RC1, so just to be sure, try RC2 and make sure to clear the error log so that old messages do not get confused for new ones.
 [2002-11-28 06:34 UTC] msopacua@php.net 
Yes, it does put out the scriptname, with the mem leaks -it's always the same script, which is nothing more than a static file which echo's the current timestamp into 8 different places for banners - that's why it doesn't make sence.

However - when an emalloc call fails, it doesn't output the scriptname nor the c file, which called the emalloc.

It only happens a few times a day, so the cause could be the memory leaks or it could be a script which isn't requested too much.

I see a SIGSEV afterwards, but no core dump and it's not like I can startup Apache from gdb and request a certain file to reproduce it, since I have no idea where to look.

I will recheck settings to make it dump core.

What's also strange is that these leaks only get reported on a SIGHUP. Through the entire error log, there are no other leak reports. This would suggest something in the SIGCHILD and therefore the shutdown handler.
 [2002-11-28 08:17 UTC] iliaa@php.net 
As a security procution Apache does not write core files, in order to make it do so you must tell it where to write core files using: CoreDumpDirectory /tmp.
In debug builds Zend will segfault if emalloc() fails to allocate memory.
Also, could you please include the list of extensions you've compiled your PHP with (put config.nice online somewhere?).
 [2002-11-28 09:00 UTC] msopacua@php.net 
CFLAGS='-O0' \
./configure \
        --prefix=/phpct \
        --with-apache=../apache_1.3.27 \
        --enable-cli \
        --disable-cgi \
        --enable-debug \
        --enable-magic-quotes \
        --disable-short-tags \
        --with-zlib \
        --with-zlib-dir=/usr \
        --enable-calendar \
        --enable-ftp \
        --with-mhash=/weblib/local \
        --enable-shmop \
        --enable-sysvmsg \
        --enable-sysvsem \
        --enable-sysvshm

waiting for a coredump.. :)
 [2002-11-30 03:36 UTC] msopacua@php.net 
Traced the segfaults to an infinite loop in one script in a situation that shouldn't normally occur (iow sloppy coding :).
I used squid in accellerator mode, to find out which script it was (For reference: grep for 'HTTP/1.[01]" 503' and use emulate_httpd_log On). It would really be nice, if emalloc failures could report some more info than 'oops, I failed'.

The memleaks are still there on SIGHUP and are unrelated. Will try RC2 this weekend.
 [2002-12-03 04:38 UTC] msopacua@php.net 
Just ran into the same 'Unable to allocate 129bytes' error with a totally different script. This is actually a bug in spprintf. The 129bytes are the allocation for the 'Maximum executions time of %d second%s execeeded' error message.

Relaying to new bug.
RC2 will be installed later today, to check the memory leaks.
Updated summary
 [2003-01-03 13:18 UTC] iliaa@php.net 
When PHP recieves the signal it stops the current execution and immidiately goes to the shutdown code. The result is that there are some non-freed buffers, who's memory you see the shutdown code free and report as memory leaks. These are not actual leaks and they can be safely ignored.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri May 09 20:01:27 2025 UTC