Is this crash easily/consistently reproducible? Is it an issue you think is
readily fixable? If this is the case, open a new bug.

Or is it really rare? Would it likely go unfixed/unvalidated fix for a long
time? If this is the case, you should add this to bug #68439, which is a
collection of hard to reproduce/rare crashes in Opcache.

The #68439 crashes may go unfixed for a long time. They are hard to
reproduce to fix or validate a fix. We don't want to have a bunch of
Opcache bugs open in Bugzilla forever. But, we want to keep a record of
such crashes. For these reasons, we're sticking all these crashes in #68439.

Regards
-M

On Mon, Nov 24, 2014 at 1:52 PM, Eric Stenson ericsten@microsoft.com
wrote:

Internals folks--

Who owns Zend Opcache these days? I've got a crash dump that appears to
be a double-free of ZCG(cwd) during accel_chdir on PHP 5.5.18.

Does this crash look familiar to anyone?

[windbg output]
0:000> .ecxr
eax=00000000 ebx=01b47cb0 ecx=77b12240 edx=01b00000 esi=01b12f08
edi=01e6e6d0
eip=6bdab9e7 esp=0194ef2c ebp=0cff53b0 iopl=0 nv up ei pl zr na pe
nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b
efl=00210246
php5!_efree+0x27:
6bdab9e7 8b57f8 mov edx,dword ptr [edi-8]
ds:002b:01e6e6c8=????????
0:000> k
*** Stack trace for last set context - .thread/.cxr resets it

ChildEBP RetAddr

00 0194ef34 6bd52647 php5!_efree+0x27
[c:\php-sdk\php55\vc11\x86\php-5.5.18\zend\zend_alloc.c @ 2440]
01 0194f044 6bda6ee6 php_opcache!zif_accel_chdir+0x67
[c:\php-sdk\php55\vc11\x86\php-5.5.18\ext\opcache\zendaccelerator.c @ 158]
02 0194f0a4 6bda6645 php5!zend_do_fcall_common_helper_SPEC+0x176
[c:\php-sdk\php55\vc11\x86\php-5.5.18\zend\zend_vm_execute.h @ 550]
03 0194f0dc 6bdc11c1 php5!execute_ex+0x295
[c:\php-sdk\php55\vc11\x86\php-5.5.18\zend\zend_vm_execute.h @ 363]
04 0194f184 6bde68d0 php5!zend_call_function+0x3c1
[c:\php-sdk\php55\vc11\x86\php-5.5.18\zend\zend_execute_api.c @ 937]
05 0194f1b8 6bde6808 php5!call_user_function_ex+0x50
[c:\php-sdk\php55\vc11\x86\php-5.5.18\zend\zend_execute_api.c @ 725]
06 0194f1f0 6bee5ae9 php5!call_user_function+0x58
[c:\php-sdk\php55\vc11\x86\php-5.5.18\zend\zend_execute_api.c @ 699]
07 0194f224 6bdbf51b php5!user_shutdown_function_call+0x79
[c:\php-sdk\php55\vc11\x86\php-5.5.18\ext\standard\basic_functions.c @ 5001]
08 0194f238 6bee17e8 php5!zend_hash_apply+0x1b
[c:\php-sdk\php55\vc11\x86\php-5.5.18\zend\zend_hash.c @ 716]
09 0194f290 6bdba9dc php5!php_call_shutdown_functions+0x48
[c:\php-sdk\php55\vc11\x86\php-5.5.18\ext\standard\basic_functions.c @ 5088]
0a 0194f5d0 01141443 php5!php_request_shutdown+0x6c
[c:\php-sdk\php55\vc11\x86\php-5.5.18\main\main.c @ 1746]
0b 0194f764 0114420c php_cgi!main+0x443
[c:\php-sdk\php55\vc11\x86\php-5.5.18\sapi\cgi\cgi_main.c @ 2505]
0c 0194f7a4 75f086e3 php_cgi!__tmainCRTStartup+0xfd
[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 536]
0d 0194f7b0 77b1be99 kernel32!BaseThreadInitThunk+0xe
[d:\win8_gdr\base\win32\client\thread.c @ 65]
0e 0194f7f4 77b1be6c ntdll!__RtlUserThreadStart+0x72
[d:\win8_gdr\minkernel\ntdll\rtlstrt.c @ 1024]
0f 0194f80c 00000000 ntdll!_RtlUserThreadStart+0x1b
[d:\win8_gdr\minkernel\ntdll\rtlstrt.c @ 939]
0:000> .frame 1
01 0194f044 6bda6ee6 php_opcache!zif_accel_chdir+0x67
[c:\php-sdk\php55\vc11\x86\php-5.5.18\ext\opcache\zendaccelerator.c @ 158]
0:000> dv
ht = 0n1
return_value = 0x0cf8e670
return_value_ptr = 0x00000000
this_ptr = 0x00000000
return_value_used = 0n0
cwd = char [260] "D:\home\site\wwwroot"
0:000> dt php_opcache!accel_globals
+0x000 function_table : _hashtable
+0x028 internal_functions_count : 0n1774
+0x02c counted : 0n0
+0x030 enabled : 0 ''
+0x031 locked : 0 ''
+0x034 bind_hash : _hashtable
+0x060 accel_directives : _zend_accel_directives
+0x0b0 cwd : 0x01e6e6d0 "--- memory read error at address
0x01e6e6d0 ---"
+0x0b4 cwd_len : 0n20
[end windbg output]

Looks like accel_globals.cwd is pointing at free'd memory.

I looked through the existing bugs on Opcache, and I didn't see any that
matched this crash. I wanted to check with the internals alias before I
opened the bug.

This is 5.5.18 NTS x86.

Thx!
--E.