ID: 23415
User updated by: bginter at ndevtech dot net
Reported By: bginter at ndevtech dot net
-Status: Open
+Status: Closed
Bug Type: Session related
Operating System: Linux 2.4.20
PHP Version: PHP 4.3.2
New Comment:
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...
Previous Comments:
------------------------------------------------------------------------
[2003-06-03 22:33:28] 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-05-15 20:46:46] 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-05-15 19:06:42] [EMAIL PROTECTED]
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 14:20:47] 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-14 13:34:42] [EMAIL PROTECTED]
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ÿ¿[EMAIL PROTECTED]ÿ¿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¯ÿ¿-ĞM@ ¾ÿ¿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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/23415
--
Edit this bug report at http://bugs.php.net/?id=23415&edit=1
