Bug #71024 [Opn]: Unable to use PHP 7.0 x64 side-by-side with PHP 5.6 x32 on the same server

From: Date: Sat, 05 Dec 2015 14:47:31 +0000
Subject: Bug #71024 [Opn]: Unable to use PHP 7.0 x64 side-by-side with PHP 5.6 x32 on the same server
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-197616@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=71024&edit=1 ID: 71024 Updated by: laruence@php.net Reported by: pvasilevich at odin dot com Summary: Unable to use PHP 7.0 x64 side-by-side with PHP 5.6 x32 on the same server Status: Open Type: Bug Package: opcache Operating System: Windows PHP Version: 7.0.0 -Assigned To: +Assigned To: dmitry Block user comment: N Private report: N New Comment: I think this is a good improvement, @Dmitry what do you think? Previous Comments: ------------------------------------------------------------------------ [2015-12-04 08:45:31] pvasilevich at odin dot com You can check proposed path or pull request https://github.com/php/php-src/pull/1661 ------------------------------------------------------------------------ [2015-12-04 08:42:50] pvasilevich at odin dot com Description: ------------ STEPS TO REPRODUCE: 1) create site in IIS and configure it to use PHP 5.6 x86 for it. 2) create virtual directory (in this case the same pool user will be used for both PHP) and configure PHP 7.0 x64 on it. 3) browse site pages that handled by PHP 5.6 - everything works fine. Notice, that C:\Windows\Temp\ZendOPcache.MemoryBase@user file was created, and process php-cgi.exe holds handle to \BaseNamedObjects\ZendOPcache.SharedMemoryArea@user shared memory 4) then try to request pages under virtual directory handled by PHP 7.0 Expected result: ---------------- There could be several solutions and workarounds here. The most elegant and stable (appropriate for all following release as well) will be solution to differentiate shared memory names, and mmap_base files by name. Proposed solution is to include PHP version and architecture in file name and shared memory name, and mutex. This can separate memory objects between different versions on servers, make it more stable. The following request looks quite similar: https://github.com/zendtech/ZendOptimizerPlus/issues/109 Actual result: -------------- 500 Internal server error. Looking at crash dump you can see: 000000de14eeeea0 00007ff9831433e1 php_opcache!accel_new_interned_string+0x27 [c:\php-sdk\php70dev\vc14\x64\php-7.0.0\ext\opcache\zendaccelerator.c @ 330] 000000de14eeeee0 00007ff9831466ca php_opcache!accel_use_shm_interned_strings+0x21 [c:\php-sdk\php70dev\vc14\x64\php-7.0.0\ext\opcache\zendaccelerator.c @ 395] 000000de14eeef20 00007ff975847634 php_opcache!accel_startup+0x1fa [c:\php-sdk\php70dev\vc14\x64\php-7.0.0\ext\opcache\zendaccelerator.c @ 2662] 000000de14eeef50 00007ff9757ab25b php7!zend_extension_startup+0x24 [c:\php-sdk\php70dev\vc14\x64\php-7.0.0\zend\zend_extensions.c @ 176] 000000de14eeef80 00007ff97544268c php7!zend_llist_apply_with_del+0x357ebb [c:\php-sdk\php70dev\vc14\x64\php-7.0.0\zend\zend_llist.c @ 171] 000000de14eeefc0 00007ff721142787 php7!php_module_startup+0x95c [c:\php-sdk\php70dev\vc14\x64\php-7.0.0\main\main.c @ 2199] 000000de14eef4c0 00007ff7211448ec php_cgi!php_cgi_startup+0x17 [c:\php-sdk\php70dev\vc14\x64\php-7.0.0\sapi\cgi\cgi_main.c @ 918] 000000de14eef4f0 00007ff721148d40 php_cgi!main+0x5bc [c:\php-sdk\php70dev\vc14\x64\php-7.0.0\sapi\cgi\cgi_main.c @ 1899] 000000de14eefa20 00007ff993271611 php_cgi!__scrt_common_main_seh+0x124 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 264] 000000de14eefa60 00007ff9935a64ad kernel32!BaseThreadInitThunk+0xd 000000de14eefa90 0000000000000000 ntdll!RtlUserThreadStart+0x1d In fact PHP 7 tries to use the same memory (looking for the same memory object name). Looks like because PHP 7 is 64-bit process, structure of the memory is different, that brings to crash. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=71024&edit=1

« previous php.bugs (#197616) next »