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"
Created attachment 39323 [details] Code which eat all available memory ... but shouldn't.
Submited also as http://bugs.php.net/30053 ...
closing as wontfix as per upstream.
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.
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
Created attachment 39700 [details] Updated leak code Few unset added ...
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 ?