|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2009-02-08 23:14 UTC] ns03ja at brocku dot ca
Description:
------------
I have 2 machines, both on the same local network (lets call
them server1 and server2), both of which are running
mutually accessible memcached servers. If I run the script
below on server1 and replace remote-server with server1,
segfaults are not observed, and the same goes for server2
connecting to server2. However, if I run the script on
server1 and replace remote-server with server2, then PHP
will segfault on me approximately 50% of the time (sometimes
more, sometimes less), and the same goes for server2
connecting to server1.
Segfaults occur in both CLI and mod_php mode.
The data stored to memcached does not seem to matter (I also
tried a string and an integer in lieu of the array).
What does seem to matter is the number of keys in the
multiget array. If I change the 2000 to 200 in the loop, I
don't get any more segfaults. The magic number seems to be
somewhere between 700 and 800 for me.
I also tried pecl-memcache 2.2.4, which does not have this
problem, while 3.0.1, 3.0.2 and 3.0.3 all exhibit this
problem.
I'm actually using PHP 5.2.8, which isn't in the list for
some reason.
Both machines are running memcached 1.2.6.
Reproduce code:
---------------
<?php
$memcache = new Memcache;
$memcache->addServer("remote-server");
$pids = array();
for ($i = 0; $i < 2000; $i++)
{
$pids[] = "pid-$i-stats";
$ar = array(
"things" => "stuff",
"thing" => 0.374822
);
$memcache->add("pid-$i-stats", $ar);
}
$memcache->get($pids);
print "no crash!\n";
?>
Expected result:
----------------
The code snippet above should never cause a segfault, but
rather (assuming the memcached server is up and running)
should always return the results as stored.
Actual result:
--------------
PHP segfaults approximately half the time.
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Mon Apr 29 12:01:32 2024 UTC |
Oops. I had built with USE=debug, but didn't realize that it still stripped the resulting binary, I was wondering why there were no line numbers. Anyways, here's backtrace version 2.0, now with line numbers! #0 0x00007fe3c968b38b in mmc_pool_select (pool=0x2a57698, timeout=0) at /var/tmp/portage/dev-php5/pecl- #1 0x00007fe3c968ac15 in mmc_pool_schedule_get (pool=0x2a57698, protocol=1, op=0, zkey=0x2af3330, value_handler=0x7fe3c9685b61 <mmc_value_handler_multi>, value_handler_param=0x7fffd679c950, failover_handler=0x7fe3c9685d73 <mmc_value_failover_handler>, failover_handler_param=0x7fffd679c940, failed_request=0x0) at /var/tmp/portage/dev-php5/pecl- #2 0x00007fe3c968610a in zif_memcache_get (ht=1, return_value=0x2b25128, return_value_ptr=0x0, this_ptr=0x2a54f08, return_value_used=0) at /var/tmp/portage/dev-php5/pecl- #3 0x00000000006fe659 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fffd679ce80) at /var/tmp/portage/dev- #4 0x00000000006ff3c4 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x7fffd679ce80) at /var/tmp/portage/dev- #5 0x00000000006fe0fc in execute (op_array=0x2a55b50) at /var/tmp/portage/dev-lang/php-5.2.8- #6 0x00000000006d5827 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /var/tmp/portage/dev- #7 0x000000000067b500 in php_execute_script (primary_file=0x7fffd679f4f0) at /var/tmp/portage/dev- #8 0x000000000076867d in main (argc=2, argv=0x7fffd679f748) at /var/tmp/portage/dev-lang/php-5.2.8- (gdb) frame 5 #5 0x00000000006fe0fc in execute (op_array=0x2a55b50) at /var/tmp/portage/dev-lang/php-5.2.8- 92 /var/tmp/portage/dev-lang/php-5.2.8- directory. in /var/tmp/portage/dev-lang/php-5.2.8- (gdb) print (char *)(executor_globals.function_state_ptr- $1 = 0x7fe3c969539f "get" (gdb) print (char *)executor_globals.active_op_array- $2 = 0x0 (gdb) print (char *)executor_globals.active_op_array- $3 = 0x2a54e98 "/home/neil/testm.php" I should also note that with debugging enabled, the crash triggers *much* less frequently, about about 1% of the time it seems.