Edit report at https://bugs.php.net/bug.php?id=65338&edit=1

 ID:                 65338
 Comment by:         phpdev at ehrhardt dot nl
 Reported by:        erics...@php.net
 Summary:            Enabling both php_opcache and php_wincache AVs on
                     shutdown
 Status:             Feedback
 Type:               Bug
 Package:            Reproducible crash
 Operating System:   Windows
 PHP Version:        5.5.1
 Block user comment: N
 Private report:     N

 New Comment:

The problem is so obvious, that I am surprised it did not com to surface
earlier. And the patch is elegant: do not assume interned_strings_start
is still the same, but free only the memory that you owned at startup.

In fact, the patch should be backported to PHP 5.4 as well. I do not
have a use case for X86, but I ran into the same problem woth PHP 5.4
X64. I know this is no official version, but as an illustration of the
problem it still is useful.

Compare these two builds:
https://dl.dropboxusercontent.com/u/8954372/php-5.4.17-nts-Win32-VC9-x64.zip
https://dl.dropboxusercontent.com/u/8954372/php-5.4.17-nts-Win32-VC9-x64_patched.zip

Try the unpatched one first. Put this in your php.ini:

extension=php_wincache.dll
zend_extension=ext/php_opcache.dll

zend_opcache.memory_consumption=128
zend_opcache.interned_strings_buffer=8
zend_opcache.max_accelerated_files=4000
zend_opcache.revalidate_freq=60
zend_opcache.fast_shutdown=1
zend_opcache.enable_cli=1

wincache.ocenabled=0
wincache.fcenabled=0    
wincache.ucachesize=768
wincache.enablecli=1
session.savehandler=wincache

Then run from the commandline in your php-directory:
php-cgi.exe -m

php-cgi will crash after showing the loaded modules. Debugging with VC9
gave this result: http://x32.elijst.nl/zendfree.png
Quite another breakpoint as in the PHP 5.5 example, but with the same
cause: freeing memory you do not own.

In the patched build I backported Eric's patch for zend_string.c to PHP
5.4. Result: no crash anymore.

A last remark: i do not think the problem is Windows specific. This is
exectly the same problem, but with the combination of opcache and apc:
http://svn.php.net/viewvc?view=revision&revision=330859


Previous Comments:
------------------------------------------------------------------------
[2013-07-26 21:07:09] me at laurinkeithdavis dot com

I can confirm that this patch works as well.

https://bugs.php.net/bug.php?id=65247

------------------------------------------------------------------------
[2013-07-26 16:48:39] phpdev at ehrhardt dot nl

@Anatol: Xinchen ran into the same problem while combining APC usercache with 
OPcache opcode cache. See
http://svn.php.net/viewvc?view=revision&revision=330859
He solved it by disabling interned_string.

@Eric: I can confirm your patch works. Tested it as well under X86 as X64.

------------------------------------------------------------------------
[2013-07-26 16:04:36] erics...@php.net

a...@php.net said
> What is the catch/sense of using both at the same time?

Wincache provides a file cache, session cache, user property cache as well as 
an opcode cache.  Further, it's possible to disable the opcode cache.

On PHP5.5, we (Wincache support folks) expect customers to enable the Zend 
opcache (because it's in 'core', and probably does more optimizing than 
Wincache does), but continue to use Wincache for file, session and user cache.

------------------------------------------------------------------------
[2013-07-26 10:58:23] a...@php.net

What is the catch/sense of using both at the same time? Both  are opcaches and 
can 
cross each other in many other hooks, most important replacing 
zend_compile_file.

It's beyond what happens, wincache replaces zend_compile_file with its own, 
followed by 
opcache replacing it with its own. Or vice versa. What happens to user trying 
to use 
the first loaded module then?

------------------------------------------------------------------------
[2013-07-26 07:01:23] a...@php.net

Related To: Bug #65247

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=65338


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65338&edit=1

Reply via email to