Description:
------------
We are hitting a bug in APC new_intern_string. When there is a hash collision 
occasionally the linked list of items becomes corrupted and p->pNext refers to 
itself and so loops indefinitely.

versions:
=========
php-apc-3.1.13

apc.ini:
========
extension=apc.so
apc.rfc1867 = 1
apc.rfc1867_freq = 50k
apc.enable = 1
apc.enable_cli = 1
apc.stat=On
realpath_cache_size=1M
realpath_cache_ttl=86400
apc.write_lock=Off
apc.shm_size=128

we suspect that write_lock may influence the behaviour but performance was not 
acceptable with it enabled.

Backtrace:
==========

apc_new_interned_string (arKey=arKey@entry=0x7f0087359120 "explodeincludepath", 
nKeyLength=nKeyLength@entry=19)
    at /root/d/php-apc-3.1.13/APC-3.1.13/apc_string.c:91
91	        p = p->pNext;
(gdb) bt
#0  apc_new_interned_string (arKey=arKey@entry=0x7f0087359120 
"explodeincludepath",
    nKeyLength=nKeyLength@entry=19) at /root/d/php-apc-3.1.13/APC-
3.1.13/apc_string.c:91
#1  0x00007f00903c8714 in apc_string_pmemcpy (str=0x7f0087359120 
"explodeincludepath", len=19,
    pool=pool@entry=0x7f0088f77b40) at /root/d/php-apc-3.1.13/APC-
3.1.13/apc_compile.c:291
#2  0x00007f00903c0735 in my_copy_zval (dst=dst@entry=0x7f0088f7bff8, 
src=src@entry=0x7f009feae030,
    ctxt=ctxt@entry=0x7fff5b0f1990) at /root/d/php-apc-3.1.13/APC-
3.1.13/apc_compile.c:348
#3  0x00007f00903c93ce in apc_copy_op_array (dst=dst@entry=0x7f0088f7bca8, 
src=src@entry=0x7f009fea8970,
    ctxt=0x7fff5b0f1990) at /root/d/php-apc-3.1.13/APC-3.1.13/apc_compile.c:1211
#4  0x00007f00903c9d1a in my_copy_function (dst=<optimised out>, dst@entry=0x0, 
src=0x7f009fea8970,
    ctxt=ctxt@entry=0x7fff5b0f1990) at /root/d/php-apc-3.1.13/APC-
3.1.13/apc_compile.c:490
#5  0x00007f00903c0426 in my_copy_hashtable_ex (dst=dst@entry=0x7f0088f77e50, 
src=src@entry=0x7f009fea7658,
    copy_fn=copy_fn@entry=0x7f00903c9c70 <my_copy_function>, 
holds_ptrs=holds_ptrs@entry=0,
    ctxt=ctxt@entry=0x7fff5b0f1990, check_fn=check_fn@entry=0x7f00903c8600 
<my_check_copy_function>)
    at /root/d/php-apc-3.1.13/APC-3.1.13/apc_compile.c:1034
#6  0x00007f00903cada4 in my_copy_class_entry (dst=0x7f0088f77e28, dst@entry=0x0, 
src=0x7f009fea7630,
    ctxt=ctxt@entry=0x7fff5b0f1990) at /root/d/php-apc-3.1.13/APC-
3.1.13/apc_compile.c:687
#7  0x00007f00903cb9d2 in apc_copy_new_classes (op_array=<optimised out>, 
old_count=old_count@entry=284,
    ctxt=ctxt@entry=0x7fff5b0f1990) at /root/d/php-apc-3.1.13/APC-
3.1.13/apc_compile.c:1544
#8  0x00007f00903cce56 in apc_compile_cache_entry (key=key@entry=0x7fff5b0f1ff0, 
h=h@entry=0x7fff5b0f3240,
    type=type@entry=2, t=t@entry=1363615582, 
op_array=op_array@entry=0x7fff5b0f1f08,
    cache_entry=cache_entry@entry=0x7fff5b0f1f00) at /root/d/php-apc-3.1.13/APC-
3.1.13/apc_main.c:446
#9  0x00007f00903cd725 in my_compile_file (h=0x7fff5b0f3240, type=2)
    at /root/d/php-apc-3.1.13/APC-3.1.13/apc_main.c:603
#10 0x00007f009ad54f32 in phar_compile_file (file_handle=<incomplete type>, 
type=32767)
    at /root/d/php5-5.4.6/ext/phar/phar.c:3391
#11 0x00007f009aea0e8c in compile_filename (type=2, filename=0x7f009fe97658) at 
Zend/zend_language_scanner.l:625
#12 0x00007f009af19eeb in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER 
(execute_data=0x7f0098626738)
    at /root/d/php5-5.4.6/Zend/zend_vm_execute.h:27386
#13 0x00007f009af37cbf in execute (op_array=0x7f00874a51f0) at /root/d/php5-
5.4.6/Zend/zend_vm_execute.h:410
#14 0x00007f009aec9158 in zend_call_function (fci=0x7fff5b0f35a0, 
fci_cache=0x7f00986260c8)
    at /root/d/php5-5.4.6/Zend/zend_execute_API.c:958

(gdb) print p
$2 = (Bucket *) 0x7f00880d9ea0
(gdb) print p->h
$4 = 11401928441719084423
(gdb) print p->arKey
$5 = 0x7f00880d9ee8 "Config must be an array or an instance of Zend_Config."
(gdb) print p->pData
$6 = (void *) 0x7f00880d9eb8
(gdb) print p->pLast
$7 = (struct bucket *) 0x7f00880d9ea0
(gdb) print p->pNext
$8 = (struct bucket *) 0x7f00880d9ea0

Under our setup "Config must be an array or an instance of Zend_Config." and 
"explodeincludepath" trigger a hash collision

We are experiencing this issue around twice a week but we are unable to reliably 
reproduce the problem. If you require additional information let us know and we 
will collect it the next time the server goes.