MMCache 2.4.1 crashes on includes
Brought to you by:
dstogov
Menu
▾
▴
#48 MMCache 2.4.1 crashes on includes
PHP 4.1.2 with MMCache 2.4.1 crashes on include_once in some
unknown circumstances, and after one crash it begins to crash every
following request to that page unless apache is restarted.
Exactly the same as with pre-2.4.0 cvs version.
Server can work some hours or days without this problem, then,
once it happens, the page starts crashing on every request. After
apache restart everything works again.
RedHat 7.3, kernel 2.4.20-19.7smp on dual Xeon, apache 1.3.27-3,
php-4.1.2-7.3.6
Project based on Smarty - 2.6.0-RC1
Logged message
MMCACHE: PHP crashed on opline 41 of fetch() at .../Smarty.class.
php:1196
function fetch(...)
{
...
if(!$this->force_compile
&& file_exists($this->_cache_paths_file)) {
include_once($this->_cache_paths_file); // <== line 1196
}
Note that files included in this operator are changed very often, they
are dynamically generated by Smarty. "Cache paths files" are created
for each Smarty compiled template, and some pages still work
(possibly, they do not include that exact file which causes crash).
The included file consists of just one long line <?php
$this->_cache_paths = unserialize('...'); ?>
Logged In: YES
user_id=876499
extension="mmcache.so"
mmcache.shm_size="16"
mmcache.cache_dir="/tmp/mmcache"
mmcache.enable="1"
mmcache.optimizer="1"
mmcache.check_mtime="1"
mmcache.debug="0"
mmcache.filter=""
mmcache.shm_max="0"
mmcache.shm_ttl="3600"
mmcache.shm_prune_period="600"
mmcache.shm_only="0"
mmcache.compress="1"
Logged In: YES
user_id=876499
Further looking into error_log, I noticed that first crashes always (3 times in
last 3 days) happen on some rarely accessed includes (include($var)), then
jumping to my case, where file is accessed and changed very often. I'd
suppose the bug is in code that removes old scripts from shared memory. I
'll try to turn it off.
Logged In: YES
user_id=876499
I've set
mmcache.shm_ttl="0"
mmcache.shm_prune_period="0"
After shared memory was filled
(Memory Size 16,777,176 Bytes
Memory Available 15,072 Bytes
Memory Allocated 16,762,104 Bytes
Cached Scripts 813)
that rarely accessed scripts with include($var) begin to give segfaults on
every request. Fortunately, frequently accessed scripts in this situation still
work properly.
Logged In: YES
user_id=876499
After I've limited the area of use of mmcache (filtered out unimportant files)
so shm cache never gets overfilled, this problem is not encountered in last 4
days.
Logged In: YES
user_id=124551
It seems one of filtered scripts cause MMCache error.
Or may be the problem comes only in situation when shared
memory is full.
Logged In: YES
user_id=876499
With PHP 4.3.3/mmcache 2.4.1 this bug has another symptoms (may be, it
is another bug?): PHP does not crash on include, it just ignores it as if
included file was empty. I get it on another machine, with only one test
project running (Smarty+PostgreSQL based), but it's too complex to make
a clean test case. There are no crashes in error_log, clean system start,
cache 32M size, concurrency is low or none. Some pages are shown as they
should be and some lose included template parts, repeatedly. If I click
Disable on mmcache control panel and reload wrong page, it is shown
correct, I click enable afterwards, reload that page, and it doesn't include
again. Restarting apache doesn't help. Click on button "Clear" helps, but not
for long, after some surfing another template becomes not included. Failed
to include templates are not shown in control panel, but I notice that
another include is there several times, while entries names and MTimes are
the same. That file gets included instead of desired file, as shown in
MMCache debug log, while it should be included once:
[3385] MMCACHE hit: ".../php/admin/index.php"
[3385] MMCACHE hit: ".../lib/config.php"
... other project includes skipped
[3385] MMCACHE hit: ".../lib/Smarty/Smarty.class.php"
[3385] MMCACHE hit: ".../lib/Smarty/core/core.get_microtime.php"
[3385] MMCACHE hit: ".../var/tpl_c/%%-59^%%
-596857780^doc_common.html.php"
[3385] MMCACHE hit: ".../var/tpl_c/%%188^%%188367230^menu.html.
php"
[3385] MMCACHE hit: ".../var/tpl_c/%%140^%%1406261667^debug.html.
php"
... here^ should be another file!
[3385] MMCACHE hit: ".../lib/Smarty/core/core.load_plugins.php"
[3385] MMCACHE hit: ".../lib/Smarty/core/core.assemble_plugin_filepath.
php"
[3385] MMCACHE hit: ".../lib/Smarty/plugins/function.assign_debug_info.
php"
... other Smarty includes skipped
[3385] MMCACHE hit: ".../var/tpl_c/%%140^%%1406261667^debug.html.
php"
... here it is in right place
Important note: in this case that debug.html is the only file that gets
rewritten by Smarty on every request, but its mtime is set every time to the
same value.
That duplicate entres are not cleaned when I click "Clean" button.
At a later time I'll try to reproduce it again with a simple test script, earlier I
failed, but not all conditions, as I see, were the same.
Logged In: YES
user_id=124551
What is your filesystem? May be the problem is here.
Try to edit mmcache.h and comment
#define MMCACHE_USE_INODE
and then rebuild mmcache
$ make clean
$ make
Clear cache from mmcache.php
# make install
Restart Apache
Logged In: YES
user_id=876499
ext3
I'll try tomorrow with 2.4.2.
About inodes I can say Smarty 2.6 writes its compiled templates into
temporary files and then renames them, so inodes change, but can be
accidentally reused by the same filename later.
PS I made a mistake.
> it just ignores it as if included file was empty
As I found later and wrote in the same posting, it is really included twice.
Logged In: YES
user_id=876499
Today I cannot reproduce the bug easily except of one extra entry in cached
files list for the same file, which cannot be "Clean"ed and which is not there
if I comment
#define MMCACHE_USE_INODE
Strange if it is triggered on and off by some changes in filesystem.
Logged In: YES
user_id=876499
Today I get that "wrong include" with PHP4.3.3/mmcache-2.4.2. Now I'll try
to recompile it without use of inodes.
PS By the way, it seems I have no crashes with preg_* functions with PHP
4.3.3, so it is some problem with 4.1.2. Now we need to upgrade
"production" server...
Logged In: YES
user_id=124551
I hope the BUG is fixed in 2.4.4 and 2.4.5.
If not, please reopen it.