Custom Query (310 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (58 - 60 of 310)

Ticket Resolution Summary Owner Reporter
#193 fixed Hash collision when files are dynamically deleted and created again moo c960657
Description

If a file is deleted and another file is created with another name immediately after, it looks as if the new file sometimes inherits the old file's inode number.

This behaviour is illustrated by the following commands. On my system the two ls calls output identical values:

rm -f file1 file2 ; touch file1 ; ls -i file1 ; rm file1 ; touch file2 ; ls -i file2

This causes a problem with XCache that (AFAICT) uses the inode number as a cache key. Thus, if a script dynamically deletes a file, oldfile.php, and subsequently creates another, newfile.php, "include 'newfile.php';" may lead to the inclusion of the code in oldfile.php. This happens e.g. with Smarty that compiles templates to PHP file.

Here is a test case in PHP:

<?php
sleep(2);
for ($i = 0; $i < 2; $i++) {
    $file = '/tmp/file' . $i . '.php';
    file_put_contents($file, '<?php var_dump("This is ' . $file . '"); ?' . '>');
    include $file;
    $stat = stat($file);
    var_dump('Now including ' . $file . ', inode=' . $stat['ino']);
    unlink($file);
}
?>

Expected result:

string(22) "This is /tmp/file0.php"
string(43) "Now including /tmp/file0.php, inode=2277518"
string(22) "This is /tmp/file1.php"
string(43) "Now including /tmp/file1.php, inode=2277518"

Actual result:

string(22) "This is /tmp/file0.php"
string(43) "Now including /tmp/file0.php, inode=2277518"
string(22) "This is /tmp/file0.php"
string(43) "Now including /tmp/file1.php, inode=2277518"

If you remove the initial "sleep(2)" it works as expected. Without the sleep() it looks as the files are never cached (they don't show up on the XCache Administration page).

#28 fixed Win32 downloads not working moo Chris
Description

Get a "page not found" error (in a weird font) at: http://trac.lighttpd.net/xcache/wiki/Win32AutoBuilds

when I try to access the Win32.

Thanks, C

#161 fixed xcache keeps on crashing, core attached moo ch@…
Description

Hello

xcache keeps on crashin. I have three core files saved with an identical backtrace:

Core was generated by `/usr/sbin/apache2 -k start'.
Program terminated with signal 11, Segmentation fault.

(gdb) bt
#0  0x00002b215f95f887 in xcache_fcall_end_handler () from /usr/lib/php5/20060613/xcache.so
#1  0x00002b215aef5db2 in get_zend_version () from /usr/lib/apache2/modules/libphp5.so
#2  0x00002b215af00cd5 in zend_hash_apply () from /usr/lib/apache2/modules/libphp5.so
#3  0x00002b215aef6247 in zend_post_deactivate_modules () from /usr/lib/apache2/modules/libphp5.so
#4  0x00002b215aeb473a in php_request_shutdown () from /usr/lib/apache2/modules/libphp5.so
#5  0x00002b215af75943 in php_ap2_register_hook () from /usr/lib/apache2/modules/libphp5.so
#6  0x0000000000432cf9 in ap_run_handler ()
#7  0x0000000000435e72 in ap_invoke_handler ()
#8  0x0000000000441fe8 in ap_process_request ()
#9  0x000000000043f4cc in ap_register_input_filter ()
#10 0x0000000000439851 in ap_run_process_connection ()
#11 0x0000000000445961 in ap_graceful_stop_signalled ()
#12 0x0000000000445bd4 in ap_graceful_stop_signalled ()
#13 0x0000000000445c76 in ap_graceful_stop_signalled ()
#14 0x00000000004468cd in ap_mpm_run ()
#15 0x0000000000420e70 in main ()

I'm running xcache-1.2.2 with apache 2.2.3-4+etch3 + php5-5.2.5 on a Debian 4.0 'etch' system with the following config:

web8:/var/cache/apache2# php -i|egrep '(jit|xcac)'

/etc/php5/cli/conf.d/xcache.ini,
auto_globals_jit => Off => Off
xcache.admin.enable_auth => On => On
xcache.cacher => On => On
xcache.coredump_directory => no value => no value
xcache.count => 8 => 8
xcache.coveragedump_directory => no value => no value
xcache.coverager => Off => Off
xcache.gc_interval => 0 => 0
xcache.mmap_path => /var/cache/apache2/php_xcache => /var/cache/apache2/php_xcache
xcache.optimizer => Off => Off
xcache.readonly_protection => 1 => 1
xcache.shm_scheme => mmap => mmap
xcache.size => 128M => 128M
xcache.slots => 16K => 16K
xcache.stat => On => On
xcache.test => no value => no value
xcache.ttl => 0 => 0
xcache.var_count => 2 => 2
xcache.var_gc_interval => 300 => 300
xcache.var_maxttl => 0 => 0
xcache.var_size => 32M => 32M
xcache.var_slots => 8K => 8K
xcache.var_ttl => 0 => 0

It's gone now and I saw a warning that I set xcache.mmap_path to a directory. Maybe that was the resason but still it definetly should not segfault!

As I had segfaults under Load for a couple of days now :(

bye,

-christian-

Note: See TracQuery for help on using queries.