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:
@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.
Previous Comments:
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
[2013-07-25 17:30:56] erics...@php.net
The following patch has been added/updated:
Patch Name: zend_interned_strings_shutdown_AV
Revision: 1374773456
URL:
https://bugs.php.net/patch-display.php?bug=65338&patch=zend_interned_strings_shutdown_AV&revision=1374773456
------------------------------------------------------------------------
[2013-07-25 17:30:31] erics...@php.net
Description:
------------
If both php_wincache.dll and php_opcache.dll are enabled, and if they are both
enabled for CLI, any script leads to an AV at process exit.
The call stack indicates that the AV is in zend_interned_strings_dtor, on the
following line:
free(CG(interned_strings_start));
This is because the value in CG(interned_strings_start) is pointing at the
chunk of memory provided by php_wincache.dll for its interned strings.
I'm seeing in the debugger that on process startup, the modules are loaded in
the order:
1. php_wincache.dll
2. php_opcache.dll
And on shutdown, they're terminated in exactly the same order.
This causes a problem, because both modules set the CG(interned_strings_start)
based upon the value it copied during startup. In this case, php_opcache.dll
copied the value that php_wincache.dll set when it started up. So, the last
value put back into CG(interned_strings_start) on shutdown was php_wincache's
interned strings buffer.
php_wincache.dll allocated the interned strings block using (zend's)
pemalloc(), but the address for CG(interned_strings_start) is an offset within
the allocation, so free() thinks the heap is corrupted.
Question:
Why are modules terminated in the same order they were initialized? For
modules that do 'hooking' of functions or memory, it seems the "unhooking"
should happen in reverse order.
php.ini settings:
zend_extension=php_opcache.dll
extension=php_wincache.dll
[opcache]
opcache.enable=1
opcache.enable_cli=1
[wincache]
wincache.enablecli=1
wincache.ocenabled=0
Test script:
---------------
<?php
$variable = 2.0;
function testGlobal()
{
global $variable;
var_dump($variable);
}
testGlobal();
$variable += 1;
testGlobal();
$variable = "Changing to string.";
testGlobal();
?>
Expected result:
----------------
No AV on shutdown
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=65338&edit=1
