php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #20802 memory limit crash
Submitted: 2002-12-03 16:12 UTC Modified: 2003-01-08 09:16 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: busia at tiscali dot it Assigned:
Status: Closed Package: Scripting Engine problem
PHP Version: 4.3.0RC2 OS: Redhat 7.0
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: busia at tiscali dot it
New email:
PHP Version: OS:

 

 [2002-12-03 16:12 UTC] busia at tiscali dot it
I have a php installation with a memory limit set to 8MB. If I try to run this script

<?
for ($i=0; $i<=10000000; $i++) {
        $var.="a";
}

echo "all is ok";
?>

I don't receive an error like "memory limit excedeed" (10MB > 8MB), simply the server kills the connection without any error on the screen or in the logs.

Server configuration:
Linux Redhat 7.0
Apache 1.3.22
PHP 4.3.0RC2
Zend Optimizer 2.0.3
Mysql 4.0.5

Configure:
'./configure' '--enable-track-vars' '--prefix=/usr' '--exec-prefix=/usr'
'--libexecdir=/usr/lib/apache' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--datadir=/home/httpd' '--sysconfdir=/etc/httpd/conf'
'--localstatedir=/var' '--libdir=/usr/lib/apache'
'--includedir=/usr/include/apache' '--mandir=/usr/man' '--with-mysql=/usr'
'--enable-memory-limit' '--with-config-file-path=/usr/local/Zend/etc'
'--with-apxs' '--with-zlib'


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-12-04 00:33 UTC] derick@php.net
Veryfied with PHP 4.4.0-dev (Nov 29 2002) and PHP 4.3.0-dev (Nov 25 2002). With both versions the script just ended without any error message, but there is no segmentation fault.

Derick
 [2002-12-08 06:19 UTC] michael dot mauch at gmx dot de
I can also verify this with 4.3.0-cvs. With the cli PHP I can get a core dump showing a nearly endless calling stack - probably the memory_limit only looks at the data size, not at the stack size (but of course this huge stack usage should not happen in the first place).

#0  0x081d0c26 in php_error_cb ()
(gdb) bt -30
#29239 0x081d0c4d in php_error_cb ()
#29240 0x08209b38 in zend_error ()
#29241 0x081f5d03 in _emalloc ()
#29242 0x081f5fc1 in _erealloc ()
#29243 0x081d4154 in xbuf_resize ()
#29244 0x081d41ec in xbuf_init ()
#29245 0x081d4f4a in vspprintf ()
#29246 0x081d0c4d in php_error_cb ()
#29247 0x08209b38 in zend_error ()
#29248 0x081f5d03 in _emalloc ()
#29249 0x081f5fc1 in _erealloc ()
#29250 0x081d4154 in xbuf_resize ()
#29251 0x081d41ec in xbuf_init ()
#29252 0x081d4f4a in vspprintf ()
#29253 0x081d0c4d in php_error_cb ()
#29254 0x08209b38 in zend_error ()
#29255 0x081f5d03 in _emalloc ()
#29256 0x081f5fc1 in _erealloc ()
#29257 0x081d4154 in xbuf_resize ()
#29258 0x081d41ec in xbuf_init ()
#29259 0x081d4f4a in vspprintf ()
#29260 0x081d0c4d in php_error_cb ()
#29261 0x08209b38 in zend_error ()
#29262 0x081f61fe in _erealloc ()
#29263 0x08205ab5 in concat_function ()
#29264 0x08218c48 in execute ()
#29265 0x08209fa4 in zend_execute_scripts ()
#29266 0x081d32dc in php_execute_script ()
#29267 0x08221707 in main ()
#29268 0x402718c1 in __libc_start_main (main=0x8220b48 <main>, argc=3, 
    argv=0xbfffe944, init=0x80792f8 <_init>, fini=0x826c8f4 <_fini>, 
    rtld_fini=0x4000a914 <_dl_fini>, stack_end=0xbfffe93c)
    at ../sysdeps/generic/libc-start.c:92
 [2002-12-13 07:24 UTC] dinoklein at hotmail dot com
I'm having the same problem with PHP 4.3RC3 with Apache 2.0.43 running with the perchild MPM.
After the crash occours, apache does not accept any more connections, even though there are other processes that could handle them, and I'm required to restart it.
Here are some outputs from ps and top, before and after the crash, perhaps it will be usefull with something:

/* I've pasted only the part that shows the "root" process, and a single child with its accompanying threads; there are 4 more children (with their threads), but they are similar and their state doesn't change */
(1) "ps ax --forest" before
 3541 ?        S      0:00 /opt/httpd-2.0.43/bin/httpd -k start
 3542 ?        S      0:00  \_ /opt/httpd-2.0.43/bin/httpd -k start
 3545 ?        S      0:00  |   \_ /opt/httpd-2.0.43/bin/httpd -k start
 3546 ?        S      0:38  |       \_ /opt/httpd-2.0.43/bin/httpd -k start
 3549 ?        S      0:00  |       \_ /opt/httpd-2.0.43/bin/httpd -k start
 3550 ?        S      0:00  |       \_ /opt/httpd-2.0.43/bin/httpd -k start
 3556 ?        S      0:00  |       \_ /opt/httpd-2.0.43/bin/httpd -k start
 3561 ?        S      0:00  |       \_ /opt/httpd-2.0.43/bin/httpd -k start
 3578 ?        S      0:00  |       \_ /opt/httpd-2.0.43/bin/httpd -k start

(2) "ps ax --forest" before
 3541 ?        S      0:00 /opt/httpd-2.0.43/bin/httpd -k start
 3542 ?        S      0:00  \_ /opt/httpd-2.0.43/bin/httpd -k start
 3545 ?        Z      0:00  |   \_ [httpd <defunct>]

(3) "top" output after the crash
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  Command      PPID nFLT nDRT WCHAN     Flags    
 3542 httpd      9   0 58028  56m 4972 S  0.0  7.5   0:00.00 /opt/httpd-  3541    1  13k rt_sigsus .....14. 
 3545 httpd      8   0     0    0    0 Z  0.0  0.0   0:00.04 ( httpd <de  3542    0    0 exit      ......44 


on previous occassions, when I did not know about this bug, I used to kill the child process with SIGTERM. That, plus other things, has yielded some lines in the apache log.

(1)This is after sending a signal:
[Thu Dec 12 20:03:16 2002] [notice] child pid 2716 exit signal Segmentation fault (11)

(2) This is probably related somehow:
[Thu Dec 12 20:14:02 2002] [info] (104)Connection reset by peer: core_output_filter: writing data to the net
work
[Thu Dec 12 20:14:03 2002] [info] (32)Broken pipe: core_output_filter: writing data to the network
 [2002-12-18 03:01 UTC] remenchuk at yahoo dot com
I have the same problem with PHP 4.2.3 on SPARC Solaris 2.7. My program is very complex and I cannot provide simple script to reproduce it.

It seems to be hitting default 8 mb memory at random points in the code when it processed enough data. 
But instead of reporting an error, PHP engine just dies and re-starts execution of the script from the very beginning (!).
No records in the logs. 

PHP is running as Apache 1.3.26 module.
 [2002-12-30 14:54 UTC] php dot net at robertoldham dot com
I have reproduced this issue with the released 4.3.0.  When the memory limit is exceeded, the program dies without the slitest indication as to why.

The exact same test with PHP 4.2.3 prints an error: "PHP Fatal error:  Allowed memory size of 10485760 bytes exhausted (tried to allocate 1 bytes) in - on line 1".  The following command line is what I used to produce the message above:

echo -n '<?php $s = ""; for ($i = 0; $i < 10000000000; $i++) {$s .= " ";} print("finished"); ?>' | php -q
 [2002-12-30 15:14 UTC] jtate@php.net
I've seen this behavior in versions as early as 4.1.2.


 [2003-01-08 09:16 UTC] iliaa@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 09:01:28 2024 UTC