Bug 63559

Summary:	PHP leaks memory if using reference
Product:	Gentoo Linux	Reporter:	Honza <hkmaly>
Component:	Current packages	Assignee:	PHP Bugs <php-bugs>
Status:	RESOLVED WONTFIX
Severity:	normal
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Attachments:	Code which eat all available memory ... but shouldn't. Updated leak code

Description Honza 2004-09-10 09:00:28 UTC

Attached code run in php (dev-php/php-4.3.8) print higher and higher memory sizes until fatal error message "Allowed memory size of (number) bytes exhausted". On top it seems that it really allocates memory and didn't free it.

Reproducible: Always
Steps to Reproduce:
1. Save attached program and run it.
2. Increase $i limit until it fills all allowed memory.


Actual Results:  
.....
.....
.....
16774088
16774416
16774744
16775072
16775400
16775728
16776056
16776384

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate
32 bytes) in /castle/hkmaly/programy/php/test_leak.php on line 6


Expected Results:  
Don't sure, something as:
20720
21816
22144
22144
22144
....
22144
22144
22144


Portage 2.0.50-r11 (default-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.4.26-gentoo-r9)
=================================================================
System uname: 2.4.26-gentoo-r9 i686 AMD Duron(tm) Processor
Gentoo Base System version 1.4.16
distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
Autoconf: sys-devel/autoconf-2.59-r3
Automake: sys-devel/automake-1.8.5-r1
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -mcpu=athlon -march=i686 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref
/usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -mcpu=athlon -march=i686 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache distcc sandbox"
GENTOO_MIRRORS="http://ftp.sh.cvut.cz/MIRRORS/gentoo/gentoo/
http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/
http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j4"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/mnt/hda04/gentoo-var-tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="3dnow X Xaw3d aalib apache2 apm arts avi berkdb bitmap-fonts caps cdr crypt
cups curl dga divx4linux doc dvd encode esd flac foomaticdb gcj gd gdbm gif gpm
gtk gtk2 imagemagick imlib innodb ipv6 java jpeg lcms lesstif libcaca libg++
libwww mad mbox mcal memlimit mikmod mmx mng motif mozilla mpeg mysql ncurses
nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba
sdl slang snmp spell sqlite sse ssl svga tcltk tcpd tetex theora tiff truetype
unicode usb vhosts videos wmf x86 xml xml2 xmms xosd xprint xv xvid zlib"

Comment 1 Honza 2004-09-10 09:02:17 UTC

Created attachment 39323 [details]
Code which eat all available memory ... but shouldn't.

Comment 2 Honza 2004-09-10 09:22:20 UTC

Submited also as http://bugs.php.net/30053 ...

Comment 3 Robin Johnson archtester

2004-09-15 02:04:59 UTC

closing as wontfix as per upstream.

Comment 4 Honza 2004-09-15 08:14:14 UTC

Ok. So they didn't fix it, because they didn't want to rewrite whole garbage collecting and half of Zend ... but it's still BUG. And another one is that big red warning, which is missing on the beginning of Chapter 19. References Explained.

Comment 5 Stuart Herbert (RETIRED) gentoo-dev

2004-09-15 13:32:53 UTC

Just a follow-up comment ...

Of course that code will eat all available memory.  Unless you call unset() explicitly, the PHP garbage collector is only guaranteed to run when your script terminates.  PHP is a scripting engine, and not a threaded virtual machine.

Best regards,
Stu

Comment 6 Honza 2004-09-16 07:42:26 UTC

Created attachment 39700 [details]
Updated leak code

Few unset added ...

Comment 7 Honza 2004-09-16 07:44:35 UTC

I've assumed that unability to allocate new structure is a good reason to run gc ... but OK, I add code to unset all variables, even local one ... and suprise, nothing changed. On what other should I call unset ?