|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2001-09-25 13:55 UTC] dshadow at zort dot net
When I unserialize a ~7mb object that contains several levels of nested objects and arrays, PHP displays abnormal behavior. (Script #1)
First, when script execution is complete, PHP uses 100% of the CPU until it has consumed the limit set by set_time_limit(). At this point, it segfaults with the following backtrace (Backtrace #1).
When compiled into Apache, this causes the memory footprint for each child process to skyrocket; the memory is not freed until the child exits. Over time, this has resulted in Apache using 70mb * 10 children = 700mb of RAM.
Additonally: I have experienced random crashes when PHP (4.0.4pl1) exits on Solaris. As I can not consistently reproduce this, I can't provide a sample script that always exhibits the problem, but the script that crashes does use mysql, and does NOT use unserialize() at all. This problem is included in this report because both crash in the same function when PHP is doing the same thing (shutting down).
Backtrace #1 - Linux / php4-200109251035
./configure --with-mysql=/usr/local/mysql --enable-track-vars --with-xml --with-imap=/usr --with-zlib-dir=/usr --with-ttf=/usr --enable-bcmath --with-kerberos=/usr/kerberos --with-openssl=/usr
Program received signal SIGSEGV, Segmentation fault.
0x80ee455 in _efree (ptr=0xa585b54) at zend_alloc.c:240
240 REMOVE_POINTER_FROM_LIST(p);
(gdb) bt
#0 0x80ee455 in _efree (ptr=0xa585b54) at zend_alloc.c:240
#1 0x80ee7eb in shutdown_memory_manager (silent=1, clean_cache=1)
at zend_alloc.c:469
#2 0x806affe in php_module_shutdown () at main.c:1008
#3 0x8069ba9 in main (argc=2, argv=0xbffffbf4) at cgi_main.c:787
Backtrace #2: Solaris / php 4.0.4pl1
./configure --with-mysql=/apps/mysql --enable-track-vars --with-xml --enable-bcmath
#0 0x89074 in _efree (ptr=0x14d1c0) at zend_alloc.c:232
232 REMOVE_POINTER_FROM_LIST(p);
(gdb) bt
#0 0x89074 in _efree (ptr=0x14d1c0) at zend_alloc.c:232
#1 0x9ad48 in zend_hash_destroy (ht=0x158008) at zend_hash.c:569
#2 0x962f8 in _zval_dtor (zvalue=0x14a328) at zend_variables.c:69
#3 0x8e9f8 in _zval_ptr_dtor (zval_ptr=0x14acf4) at zend_execute_API.c:261
#4 0x9acdc in zend_hash_destroy (ht=0x11fdf4) at zend_hash.c:564
#5 0x8e824 in shutdown_executor () at zend_execute_API.c:165
#6 0x96ffc in zend_deactivate () at zend.c:525
#7 0x24c38 in php_request_shutdown (dummy=0x0) at main.c:688
#8 0x23a78 in main (argc=3, argv=0xeffffd34) at cgi_main.c:771
Script #1:
#!/usr/local/bin/php -q
<?
set_time_limit(5);
$fn = '/path/to/very-lage-serialized.file';
$fd = fopen($fn, 'r');
$str = fread($fd, filesize($fn));
$us = unserialize($str);
?>
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Fri Nov 01 01:01:28 2024 UTC |
I've seen this as well. The time limit you set is removed when the script finishes but before the memory is cleaned up. What I did to avoid the problem was to change the code in php_request_shutdown() main/main.c. The end of the function looks like: zend_try { shutdown_memory_manager(CG(unclean_shutdown), 0); } zend_end_try(); zend_try { zend_unset_timeout(TSRMLS_C); } zend_end_try(); I switched the timeout and the shutdown, and then it worked for me. It still takes a long time, but you don't get a timeout. Not sure if this is the correct fix, but maybe you want to test and confirm that it helps?