php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23415 memory overrun/crash n session serialization(?)/objects/references w/time limit
Submitted: 2003-04-29 13:10 UTC Modified: 2003-08-08 04:44 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: bginter at ndevtech dot net Assigned:
Status: Closed Package: Session related
PHP Version: 4.3.2 OS: Linux 2.4.20
Private report: No CVE-ID: None
 [2003-04-29 13:10 UTC] bginter at ndevtech dot net
<?php
error_reporting(E_ALL);
ob_implicit_flush();
set_time_limit( 30 );

class Group {
    var $list     = array();
    var $position = 0;
    
    //--------------------------------------------------------------------
    //
    //--------------------------------------------------------------------
    function add ( $value ) {
        if ( isset( $value ) ) {
            $this->list[] = $value;
            $this->position = sizeof( $this->list ) - 1;
            return 1;
        }
        return 0;
    }

    //--------------------------------------------------------------------
    //
    //--------------------------------------------------------------------
    function &get ( $value ) {
        if ( is_array( $this->list ) && 
	     isset( $value )         && 
	     is_numeric( $value )    && 
	     $value >= 0             &&
	     $value < $this->count() ) 
	{
            return $this->list[$value];
        }
	return NULL;
    }

    //--------------------------------------------------------------------
    //
    //--------------------------------------------------------------------
    function count () {
        return count( $this->list );
    }   

}

session_name( 'crash3' );
session_start();

if ( !session_is_registered( 'group1' ) ) {
    session_register( 'group1' );

    $group1 = new Group;
    
    for ( $i = 0; $i < 3; $i++ ) {
	$subgroup = new Group;
	
	for ( $j = 0; $j < 3; $j++ ) {
	    $subgroup->add( "Subgroup $i Element $j" );
	}
	
	$group1->add( $subgroup );
    }
}

for ( $i = 0; $i < $group1->count(); $i++ ) {
    $subgroup = $group1->get( $i );
    for ( $j = 0; $j < $subgroup->count(); $j++ ) {
	$element = $subgroup->get( $j );
	print $element . "<br/>\n";
    }
}

$group2 = new Group;
while ( true ) {
    for ( $i = 0; $i < $group1->count(); $i++ ) {
	
	// $subgroup = $group1->get( $i );

	// Uncomment this and comment line above for Overrun messages
	$subgroup =& $group1->get( $i );

	$group2->add( $subgroup );
    }
}

exit;
?>

This code consistantly crashes PHP, including the latest CVS 
snapshot (php4-STABLE-200304291730).  I expected it to simply
stop executing after the time limit was reached.

If the session code is commented/removed, it does not crash.  

In the second code block, if an ampersand is added to the get()
method call, the script does not segfault consistantly but 
produces errors in the Apache log concerning overruns:

e.g.
[Tue Apr 29 11:03:19 2003]  Script:  '/usr/local/apache/lariat/lariat2/test/test4/crash3.php'
---------------------------------------
/usr/local/src/php4-STABLE-200304291730/Zend/zend_execute.h(44) : Block 0x0816DB20 status:
Beginning:  	Overrun (magic=0x0816D548, expected=0x7312F8DC)
      End:	Unknown
---------------------------------------

The relevant lines of the backtrace are provided below.  The call to 
php_var_serialize_intern is repeated tens of thousands of times.

Program received signal SIGSEGV, Segmentation fault.
smart_str_print_unsigned (buf=0xbf800087 "@\210?3@?\001\200?\222?9@t???ta\026\b?\001\200?o?9@?OT@h\n\026\b?", num=135684468)
    at /usr/local/src/php4-STABLE-200304291730/ext/standard/php_smart_str.h:90
90	{
(gdb) bt
#0  smart_str_print_unsigned (buf=0xbf800087 "@\210?3@?\001\200?\222?9@t???ta\026\b?\001\200?o?9@?OT@h\n\026\b?", num=135684468)
    at /usr/local/src/php4-STABLE-200304291730/ext/standard/php_smart_str.h:90
#1  0x4039ddef in php_add_var_hash (var_hash=0xbffff174, var=0x8166174, var_old=0xbf8001e4) at /usr/local/src/php4-STABLE-200304291730/ext/standard/var.c:377
#2  0x4039d392 in php_var_serialize_intern (buf=0xbffff1a0, struc=0x1416d9d0, var_hash=0xbffff174)
    at /usr/local/src/php4-STABLE-200304291730/ext/standard/var.c:489
#3  0x4039d897 in php_var_serialize_intern (buf=0xbffff1a0, struc=0x1416cb78, var_hash=0xbffff174)
    at /usr/local/src/php4-STABLE-200304291730/ext/standard/var.c:598

This is Apache 1.3.27 with php4-STABLE-200304291730 compiled with:

./configure \
--prefix=/usr/local/php_4.3.1 \
--with-apxs=/usr/local/apache/bin/apxs \
--enable-bcmath \
--enable-gd-native-ttf \
--with-gd \
--with-ttf \
--enable-calendar \
--with-mysql \
--with-openssl \
--with-iconv \
--enable-xml \
--with-pgsql=/usr/local/pgsql-7.3 \
--with-mcrypt \
--with-curl \
--with-zip \
--enable-ftp \
--with-zlib-dir=/usr \
--enable-debug

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-05-14 13:34 UTC] vlad@php.net
In my case I can't get it to crash, but instead I see this in the logs:

May 14 11:34:21 wb-01 project.ipv: PHP Fatal error:  Cannot redeclare class baseobject:hosting in /imprev/include/hosting.inc on line 10
May 14 11:34:28 wb-01 \204W^Z^H: PHP Fatal error:  Cannot redeclare class baseobject:hosting in /imprev/include/hosting.inc on line 10
May 14 11:34:48 wb-01 autoForms.ip\200^C: PHP Fatal error:  Cannot redeclare class baseobject:hosting in /imprev/include/hosting.inc on line 10
May 14 11:35:02 wb-01 (\237&#255;&#191;-?M@\220?&#255;&#191;v: PHP Fatal error:  Cannot redeclare class baseobject:hosting in /imprev/include/hosting.inc on line 10
May 14 11:35:55 wb-01 : PHP Fatal error:  Cannot redeclare class baseobject:hosting in /imprev/include/hosting.inc on line 10
May 14 11:37:12 wb-01 8&#175;&#255;&#191;-?M@ &#190;&#255;&#191;nsCoA: PHP Fatal error:  Cannot redeclare class baseobject:hosting in /imprev/include/hosting.inc on line 10
May 14 11:37:15 wb-01 ^B\210P@: PHP Fatal error:  Cannot redeclare class baseobject:hosting in /imprev/include/hosting.inc on line 10
May 14 11:37:30 wb-01 ^S: PHP Fatal error:  Cannot redeclare class baseobject:hosting in /imprev/include/hosting.inc on line 10
May 14 11:38:10 wb-01 ^C: PHP Fatal error:  Cannot redeclare class baseobject:hosting in /imprev/include/hosting.inc on line 10
May 14 11:39:05 wb-01 i: PHP Fatal error:  Cannot redeclare class baseobject:hosting in /imprev/include/hosting.inc on line 10
May 14 11:39:23 wb-01 A: PHP Fatal error:  Cannot redeclare class baseobject:hosting in /imprev/include/hosting.inc on line 10

Notice the garbage instead of the filename. The website uses classes extensively, and other pages seem to work just fine while this is the only one that bombs (started to bomb earlier today after working for a few weeks with no trouble). I can't verify that this is the SAME bug, but it sure does look similar.
 [2003-05-15 14:20 UTC] bginter at ndevtech dot net
Unfortunately, the bug persists.

In the final loop of the example code, taking a reference using the following line causes overrun warnings in the log file:

   $subgroup =& $group1->get( $i );

Some sample error messages:

---------------------------------------
/usr/local/src/php4-STABLE-200305151730/Zend/zend_execute.h(44) : Block 0x08308530 status:
Beginning:  	Overrun (magic=0x0831CB40, expected=0x7312F8DC)
      End:	Unknown
---------------------------------------
/usr/local/src/php4-STABLE-200305151730/Zend/zend_execute.h(44) : Block 0x08307648 status:
Beginning:  	Overrun (magic=0x40252868, expected=0x7312F8DC)
      End:	Unknown
---------------------------------------


In the final loop of the example code, taking a copy using the following line causes a repeatable segmentation fault.

   $subgroup = $group1->get( $i );


Here is the relevant lines of the backtrace.  Note that after line 3, the php_var_serialize_intern line is repeated thousands of times. 

Program received signal SIGSEGV, Segmentation fault.
0x40426333 in _mem_block_check (ptr=0x830d4d4, silent=1, __zend_filename=0x4050a040 "/usr/local/src/php4-STABLE-200305151730/Zend/zend_execute_API.c", 
    __zend_lineno=488, __zend_orig_filename=0x4050a720 "/usr/local/src/php4-STABLE-200305151730/Zend/zend_variables.c", __zend_orig_lineno=44)
    at /usr/local/src/php4-STABLE-200305151730/Zend/zend_alloc.c:675
675		memcpy(&end_magic, (((char *) p)+sizeof(zend_mem_header)+MEM_HEADER_PADDING+p->size), sizeof(long));
(gdb) bt
#0  0x40426333 in _mem_block_check (ptr=0x830d4d4, silent=1, __zend_filename=0x4050a040 "/usr/local/src/php4-STABLE-200305151730/Zend/zend_execute_API.c", 
    __zend_lineno=488, __zend_orig_filename=0x4050a720 "/usr/local/src/php4-STABLE-200305151730/Zend/zend_variables.c", __zend_orig_lineno=44)
    at /usr/local/src/php4-STABLE-200305151730/Zend/zend_alloc.c:675
#1  0x40425464 in _efree (ptr=0x830d4d4, __zend_filename=0x4050a040 "/usr/local/src/php4-STABLE-200305151730/Zend/zend_execute_API.c", __zend_lineno=488, 
    __zend_orig_filename=0x4050a720 "/usr/local/src/php4-STABLE-200305151730/Zend/zend_variables.c", __zend_orig_lineno=44)
    at /usr/local/src/php4-STABLE-200305151730/Zend/zend_alloc.c:243
#2  0x40438a36 in _zval_dtor (zvalue=0xbf800188, __zend_filename=0x4050a040 "/usr/local/src/php4-STABLE-200305151730/Zend/zend_execute_API.c", __zend_lineno=488)
    at /usr/local/src/php4-STABLE-200305151730/Zend/zend_variables.c:44
#3  0x4042f290 in call_user_function_ex (function_table=0x830e648, object_pp=0x1430e5d0, function_name=0xbf80021c, retval_ptr_ptr=0xbf800228, param_count=0, 
    params=0x0, no_separation=1, symbol_table=0x0) at /usr/local/src/php4-STABLE-200305151730/Zend/zend_execute_API.c:488
#4  0x403beb21 in php_var_serialize_intern (buf=0xbffff1a0, struc=0x1430e5d0, var_hash=0xbffff174)
    at /usr/local/src/php4-STABLE-200305151730/ext/standard/var.c:534
#5  0x403bed84 in php_var_serialize_intern (buf=0xbffff1a0, struc=0x1430d778, var_hash=0xbffff174)
    at /usr/local/src/php4-STABLE-200305151730/ext/standard/var.c:599


PHP was compiled with:

./configure \
--prefix=/usr/local/php_4.3.1 \
--with-apxs=/usr/local/apache/bin/apxs \
--enable-bcmath \
--enable-gd-native-ttf \
--with-gd \
--with-ttf \
--enable-calendar \
--with-mysql \
--with-openssl \
--with-iconv \
--enable-xml \
--with-pgsql=/usr/local/pgsql-7.3 \
--with-mcrypt \
--with-curl \
--with-zip \
--enable-ftp \
--with-zlib-dir=/usr \
--enable-debug
 [2003-05-15 19:06 UTC] sniper@php.net
With PHP 4.3.2RC3 I get only this:

Fatal error: Allowed memory size of 104857600 bytes exhausted (tried to allocate 32 bytes) in /www/apache-1.3.27/htdocs/t.php on line 83

Fatal error: Allowed memory size of 105906208 bytes exhausted (tried to allocate 130 bytes) in Unknown on line 0

Try PHP 4.3.2RC3 and add --enable-memory-limit to your configure line.

 [2003-05-15 20:46 UTC] bginter at ndevtech dot net
With PHP4.2.3RC3 and --enable-memory-limit, I do get the same warning messages you provided.  

When the limit is set to 100M like in your example, subsequent reloads of that page seem to silently fail.  That is, no error/warning messages are displayed and no apache processes are churning up to 100MB.  How the process escapes the infinite loop in the example is a mystery.

When the limit is set to 250M, the crashes still occur as in previous entries on this bug.  I can provide an updated backtrace if requested.

When the limit is set to the default (16M), the crashes do not occur.  Subsequent reloads of the page show an ever increasing memory size limit:

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 44 bytes) in /usr/local/apache/lariat/lariat2/test/crash.php on line 68
Fatal error: Allowed memory size of 17825808 bytes exhausted (tried to allocate 35 bytes) in /usr/local/apache/lariat/lariat2/test/crash.php on line 12
Fatal error: Allowed memory size of 18874424 bytes exhausted (tried to allocate 40 bytes) in /usr/local/apache/lariat/lariat2/test/crash.php on line 24
Fatal error: Allowed memory size of 19923024 bytes exhausted (tried to allocate 44 bytes) in /usr/local/apache/lariat/lariat2/test/crash.php on line 68
Fatal error: Allowed memory size of 20971648 bytes exhausted (tried to allocate 41 bytes) in /usr/local/apache/lariat/lariat2/test/crash.php on line 10
etc...

Let me stress that my code doesn't utilize memory like in the example program.  The example demonstrates the bug in a short amount of code and exaggerates something that seems to have been occuring in my code on a more subtle level.

I believe that the memory limit is not a fix and at best only masks the bug.  Maybe the increasing value in the exhausted memory errors are a clue to the root cause of this bug?
 [2003-06-03 22:33 UTC] bginter at ndevtech dot net
Yes, it persists in 4.3.2.  Has anything been addressed to warrant trying a snapshot?

I don't want this bug to be forgotten and I intend to follow up until it can get fixed.  So please let me know how I can assist further.

Thank you.


Program received signal SIGSEGV, Segmentation fault.
0x40426ef3 in _mem_block_check (ptr=0x8309e8c, silent=1, __zend_filename=0x4050a1c0 "/usr/local/src/php-4.3.2/Zend/zend_execute_API.c", __zend_lineno=488, 
    __zend_orig_filename=0x4050a840 "/usr/local/src/php-4.3.2/Zend/zend_variables.c", __zend_orig_lineno=44) at /usr/local/src/php-4.3.2/Zend/zend_alloc.c:675
675		memcpy(&end_magic, (((char *) p)+sizeof(zend_mem_header)+MEM_HEADER_PADDING+p->size), sizeof(long));
(gdb) bt
#0  0x40426ef3 in _mem_block_check (ptr=0x8309e8c, silent=1, __zend_filename=0x4050a1c0 "/usr/local/src/php-4.3.2/Zend/zend_execute_API.c", __zend_lineno=488, 
    __zend_orig_filename=0x4050a840 "/usr/local/src/php-4.3.2/Zend/zend_variables.c", __zend_orig_lineno=44) at /usr/local/src/php-4.3.2/Zend/zend_alloc.c:675
#1  0x40425d54 in _efree (ptr=0x8309e8c, __zend_filename=0x4050a1c0 "/usr/local/src/php-4.3.2/Zend/zend_execute_API.c", __zend_lineno=488, 
    __zend_orig_filename=0x4050a840 "/usr/local/src/php-4.3.2/Zend/zend_variables.c", __zend_orig_lineno=44) at /usr/local/src/php-4.3.2/Zend/zend_alloc.c:243
#2  0x404395f6 in _zval_dtor (zvalue=0xbf800188, __zend_filename=0x4050a1c0 "/usr/local/src/php-4.3.2/Zend/zend_execute_API.c", __zend_lineno=488)
    at /usr/local/src/php-4.3.2/Zend/zend_variables.c:44
#3  0x4042fe50 in call_user_function_ex (function_table=0x8580898, object_pp=0x14317f78, function_name=0xbf80021c, retval_ptr_ptr=0xbf800228, param_count=0, 
    params=0x0, no_separation=1, symbol_table=0x0) at /usr/local/src/php-4.3.2/Zend/zend_execute_API.c:488
#4  0x403bf119 in php_var_serialize_intern (buf=0xbffff1a0, struc=0x14317f78, var_hash=0xbffff174) at /usr/local/src/php-4.3.2/ext/standard/var.c:534
#5  0x403bf384 in php_var_serialize_intern (buf=0xbffff1a0, struc=0x14317120, var_hash=0xbffff174) at /usr/local/src/php-4.3.2/ext/standard/var.c:599
#6  0x403bf384 in php_var_serialize_intern (buf=0xbffff1a0, struc=0x14317f78, var_hash=0xbffff174) at /usr/local/src/php-4.3.2/ext/standard/var.c:599
 [2003-08-07 14:34 UTC] bginter at ndevtech dot net
Since it doesn't appear this bug will be fixed any time soon, we have already rewritten our software to use mod_perl.  I will no longer follow up on this bug.

What a waste of time and money...
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Tue Jul 15 10:01:30 2025 UTC