I just re-reviewed the linked Chronos issue and realized that one user has seen this with Apache and suphp.  So the problem is not exclusive to mod_php.

Re-examining the Chronos issue linked and just improved the description of the PHP versions and OSes impacted.

Please note that despite the Chronos issue being opened a couple of days ago, the original CakePHP issue was opened almost a year ago.  This has been a problem for some time.

I have managed to gather a Call Stack when Apache crashes.  Here are the messages from the Apache error log immediately before the crash:

[Fri Jun 30 15:44:18.309323 2017] [php7:error] [pid 3444:tid 2756] [client ::1:10998] PHP Fatal error:  Class Cake\\Chronos\\MutableDateTime contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Cake\\Chronos\\ChronosInterface::__wakeup) in C:\\genesis\\vendor\\cakephp\\chronos\\src\\MutableDateTime.php on line 51, referer: <snip>
[Fri Jun 30 15:44:18.310323 2017] [php7:error] [pid 3444:tid 2764] [client ::1:10995] PHP Fatal error:  Class Cake\\Chronos\\MutableDateTime contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Cake\\Chronos\\ChronosInterface::__wakeup) in C:\\genesis\\vendor\\cakephp\\chronos\\src\\MutableDateTime.php on line 51, referer: <snip>
[Fri Jun 30 15:44:18.328325 2017] [php7:error] [pid 3444:tid 2772] [client ::1:10997] PHP Fatal error:  Class Cake\\Chronos\\MutableDate contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (Cake\\Chronos\\ChronosInterface::getTimezone, Cake\\Chronos\\ChronosInterface::__wakeup) in C:\\genesis\\vendor\\cakephp\\chronos\\src\\MutableDate.php on line 50, referer: <snip>



Here is the Call Stack from Visual Studio:

ntdll.dll!RtlSizeHeap()	Unknown
AcXtrnal.dll!NS_FaultTolerantHeap::APIHook_RtlFreeHeap(void *,unsigned long,void *)	Unknown
ucrtbase.dll!free()	Unknown
php7ts.dll!zend_hash_reverse_apply(_zend_array * ht, int(*)(_zval_struct *) apply_func) Line 1603	C
php7ts.dll!shutdown_executor() Line 376	C
php7ts.dll!zend_deactivate() Line 1001	C
php7ts.dll!php_request_shutdown(void * dummy) Line 1880	C
php7apache2_4.dll!php_handler(request_rec * r) Line 725	C
libhttpd.dll!000000007475e9e5()	Unknown
libhttpd.dll!000000007475d7e0()	Unknown
libhttpd.dll!000000007475a1e6()	Unknown
mod_rewrite.so!00000000743753c8()	Unknown
libhttpd.dll!000000007475e9e5()	Unknown
libhttpd.dll!000000007475d7e0()	Unknown
libhttpd.dll!000000007475a49a()	Unknown
libhttpd.dll!000000007475a527()	Unknown
libhttpd.dll!0000000074753b73()	Unknown
libhttpd.dll!0000000074761885()	Unknown
libhttpd.dll!0000000074761675()	Unknown
libhttpd.dll!0000000074771734()	Unknown
[External Code]

FWIW here is the Visual Studio:

The thread 0x346c has exited with code 0 (0x0).
The thread 0x359c has exited with code 0 (0x0).
The thread 0x804 has exited with code 0 (0x0).
'httpd.exe' (Win32): Unloaded 'C:\Windows\System32\security.dll'
Unhandled exception at 0x0000000077346789 (ntdll.dll) in httpd.exe: 0xC0000005: Access violation reading location 0x00000AEE2AF79F18.

The thread 0x37e0 has exited with code 0 (0x0).
'httpd.exe' (Win32): Unloaded 'C:\Windows\System32\1033\msodbcsqlr13.rll'
Exception thrown at 0x0000000077346789 (ntdll.dll) in httpd.exe: 0xC0000005: Access violation reading location 0x00000AEE2AF79F18.

Unhandled exception at 0x0000000077346789 (ntdll.dll) in httpd.exe: 0xC0000005: Access violation reading location 0x00000AEE2AF79F18.

Exception thrown at 0x0000000077346789 (ntdll.dll) in httpd.exe: 0xC0000005: Access violation reading location 0x00000AEE2AF79F18.

Unhandled exception at 0x0000000077346789 (ntdll.dll) in httpd.exe: 0xC0000005: Access violation reading location 0x00000AEE2AF79F18.

Exception thrown at 0x0000000077346789 (ntdll.dll) in httpd.exe: 0xC0000005: Access violation reading location 0x00000AEE2AF79F18.

... (repeating many times)

Are you using opcache? Are you using ZTS builds?

If the answers are no and yes, this sounds like it might be a persistent string corruption issue, in which case you should check whether using a PHP 7.2 alpha resolves the issue.

Thanks for taking time to look and comment on this problem.

The PHP_ZTS constant is set to 1 (so yes to ZTS build?).  It is the thread safe windows build from php.net.

I am not setting any opcache configuration items in PHP.ini, so if I understand the docs correctly that means I am getting opcache.enable = 1 by default?  Please correct me if I'm wrong on this.

So yes to ZTS and yes to opcache enabled (I think).

My database driver (SQL server) does not support PHP 7.2 yet so I'm not sure if I can test 7.2 or not.  I will try.

Will disabling opcache with 7.1 fix the problem as well?

Opcache is not loaded by default, so if you did not explicitly enable the extension, you're not using opcache (though you can double check using e.g. phpinfo()).

@ab: Can you please check whether this looks like a persistent string issue to you that will be resolved by 7.2?

@nikic, looks pretty much like the topic. TS SAPI, sporadic fails, very much like in many other bugs.

@mike dot fellows at shaw dot ca which exact extension do you need to be present to test your code under 7.2? If it builds with 7.2, i can provide it so you can have the exact constellation. It'd be great also if you could provide a backtrace, even a minidump from WER, etc.

Thanks.

Ah, i see i've overseen the backtraces already there. Yeah, the part like this

AcXtrnal.dll!NS_FaultTolerantHeap::APIHook_RtlFreeHeap(void *,unsigned long,void *)	Unknown
ucrtbase.dll!free()	Unknown
php7ts.dll!zend_hash_reverse_apply(_zend_array * ht, int(*)(_zval_struct *) apply_func) Line 1603	C
php7ts.dll!shutdown_executor() Line 376	C
php7ts.dll!zend_deactivate() Line 1001	C
php7ts.dll!php_request_shutdown(void * dummy) Line 1880	C
php7apache2_4.dll!php_handler(request_rec * r) Line 725	C

looks very much like the issue already fixed in 7.2. No further backtrace needed.

Thanks.

@nikic definitely not using opcache then as nothing was showing in php_info, and I have not enabled it.

I can capture more backtraces if you change your minds, it is not a big deal to do.

Are they any recommendations for avoiding this problem in 7.1?  Or is the only option to use 7.2?

For 7.2 The only extension I would need beyond the standard PHP ones is the Microsoft SQL Server driver for PHP:

https://github.com/Microsoft/msphpsql

No 7.2 support yet (https://github.com/Microsoft/msphpsql/issues/444).  I can't imagine that much has changed between 7.1 to 7.2 though.  I'll see about building it next week for 7.2 and see what happens.

I'm not really in a jam with this yet, but I will need to have some kind of workaround ready in about 8-10 weeks - I think a 7.2 PHP beta would be fine.  Right now this problem is just a (very minor) development headache.

Thx again for your help with this.

The repo linked contains at least two exts, pdo_sqlsrv and sqlsrv. Which one do you use? Also, which flavour, x64, x86, etc. These exts are on PECL, so some latest release could be built. Right now it looks like it's indeed the known issue already fixed in 7.2, so it would be great to have confirmed.

For 7.1 - as long as it's mod_winnt + PHP, there's no sublime workaround :( Moving to FCGI might show some more stability.

Thanks.

I'm using the 64 bit thread safe pdo_sqlsrv extension.

I'm happy to test as much as I can, be great if you think you can build the extension.  But I can do it as well.

I won't be able to start testing until Tuesday at the earliest though.

Cheers.

Here you are http://windows.php.net/downloads/snaps/ostc/74833/php_pdo_sqlsrv-4.3.0rc1-7.2-ts-vc15-x64.zip

Thanks.

@ab thanks for build the MS SQL server extension.  Unfortunately I get a 401 error when I try to download it (Access is denied due to invalid credentials).  Not sure how to get around that one.

I've just unpacked it here http://windows.php.net/downloads/snaps/ostc/74833/pdo_sqlsrv/ts/vc15/x64/ , could you please check? Seems that's the server config that doesn't like it for some reason.

Thanks.

Oh, or the zip. I think I was just able to fix the permissions.

Thanks.

Got it, thanks.  I will let you know how the testing goes in the next few days.

@ab I've been testing php7.2.0 alpha2 for the last two days.  I was not able to test it as much as I'd like because I've been fixing application bugs due to 7.2 changes.  There were no crashes for the last two days.  But this morning I did have a crash.

Here is the error output from Visual Studio:

The thread 0x28d8 has exited with code 0 (0x0).
The thread 0xa50 has exited with code 0 (0x0).
The thread 0x1668 has exited with code 0 (0x0).
Unhandled exception at 0x000007FED85F2A44 (php7ts.dll) in httpd.exe: 0xC0000005: Access violation reading location 0x0000000000000000.


And here is the Call Stack:

php7ts.dll!zif_get_defined_constants(_zend_execute_data * execute_data, _zval_struct * return_value) Line 2103	C
php7ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_RETVAL_USED_HANDLER(_zend_execute_data * execute_data) Line 827	C
php7ts.dll!execute_ex(_zend_execute_data * ex) Line 59218	C
php7ts.dll!zend_execute(_zend_op_array * op_array, _zval_struct * return_value) Line 63244	C
php7ts.dll!zend_execute_scripts(int type, _zval_struct * retval, int file_count, ...) Line 1538	C
php7ts.dll!php_execute_script(_zend_file_handle * primary_file) Line 2548	C
php7apache2_4.dll!php_handler(request_rec * r) Line 702	C
libhttpd.dll!000000007422e9e5()	Unknown
libhttpd.dll!000000007422d7e0()	Unknown
libhttpd.dll!000000007422a1e6()	Unknown
mod_rewrite.so!0000000073ed53c8()	Unknown
libhttpd.dll!000000007422e9e5()	Unknown
libhttpd.dll!000000007422d7e0()	Unknown
libhttpd.dll!000000007422a49a()	Unknown
libhttpd.dll!000000007422a527()	Unknown
libhttpd.dll!0000000074223b73()	Unknown
libhttpd.dll!0000000074231885()	Unknown
libhttpd.dll!0000000074231675()	Unknown
libhttpd.dll!0000000074241734()	Unknown
[External Code]


I notice that alpha 3 was released today.  I will upgrade to that release and continue with my testing.

Thanks for that. So there might be still some leftover. Did your system generate a minidump? Or, maybe you've found some better way to repro?

On your side, i would try to make some stress test while using get_defined_constants(). Like use ab with high concurrency. With or without your app, with core only and with full set of the exts you use. While the last backtrace is different, it could be still some leftover not fixed, or something completely different. Lets see for further info.

Thanks.

I've been running the 7.2 alpha3 release for almost a week now without any crashes.  I only saw the one crash in alpha2 I noted in my comment above.

I have not been doing any specific testing to try to trigger the bug.  Just the normal development work with CakePHP, including it's Chronos package, which was triggering crashes regularly in my windows environment with 7.1.  Before I changed to 7.2 alpha2/3 I was seeing about 10-15 crashes a day.  So a very big improvement with the 7.2 alpha releases.

I will continue to work with 7.2 and report any new crashes when/if they happen.  I can also create a full dump from SQL studio if any occur.

I've seen another crash, this one with 7.2 alpha 3.  Here is the Call Stack from Visual Studio:

php7ts.dll!zif_get_defined_constants(_zend_execute_data * execute_data, _zval_struct * return_value) Line 2102	C
php7ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_RETVAL_USED_HANDLER(_zend_execute_data * execute_data) Line 827	C
php7ts.dll!execute_ex(_zend_execute_data * ex) Line 59085	C
php7ts.dll!zend_execute(_zend_op_array * op_array, _zval_struct * return_value) Line 63117	C
php7ts.dll!zend_execute_scripts(int type, _zval_struct * retval, int file_count, ...) Line 1491	C
php7ts.dll!php_execute_script(_zend_file_handle * primary_file) Line 2550	C
php7apache2_4.dll!php_handler(request_rec * r) Line 702	C
libhttpd.dll!00000000549ae9e5()	Unknown
libhttpd.dll!00000000549ad7e0()	Unknown
libhttpd.dll!00000000549aa1e6()	Unknown
mod_rewrite.so!000000006f3353c8()	Unknown
libhttpd.dll!00000000549ae9e5()	Unknown
libhttpd.dll!00000000549ad7e0()	Unknown
libhttpd.dll!00000000549aa49a()	Unknown
libhttpd.dll!00000000549aa527()	Unknown
libhttpd.dll!00000000549a3b73()	Unknown
libhttpd.dll!00000000549b1885()	Unknown
libhttpd.dll!00000000549b1675()	Unknown
libhttpd.dll!00000000549c1734()	Unknown
[External Code]

Same as the previous one it seems.

I have saved a mini dump with the heap. The file is about 160 MBytes.  @ab if you would like the dump file does bugs.php.net have a way to upload the file somehow?

I also have just the mini-dump.  It is about 1 MByte in size.

Thanks for staying on this. Nope, bugs.php.net doesn't have this facilities. But a couple of days ago I've seen people sharing files through https://www.transfernow.net/en/ , any other service like that will suffice. The full dump were of course great. Please ensure before, that it doesn't contain any sensitive data.

So basically it's get_defined_constants() that has some issues. It would still make sense to check a reproduce possibility. As it might be something simple, or something that depends on the app code or the extensions constellation, etc. Anyway, a dump is a good start already.

Thanks.

@ab, I have emailed you a link to the minidump with heap.

@mike thanks for the crash dump. I'll get back to you with some findings after investigating on it.

Thanks.

Finally i got to the point on this. After the investigation, I don't see any issues with the string interning. I'm going to push a patch soon. Otherwise, you might have luck with reproducing on alpha3 with the code like this

session_start();
session_regenerate_id();
session_regenerate_id();
get_defined_constants(true);


I'm pretty sure the issue lays on the SID constant handling, but i don't reproduce it on my environment. I guess it depends very much on your application logic and ini, maybe some system specific factor, too. So you might luck reproducing it either by stress testing the snippet above or even better by analyzing your application and paying attention to the parts where session_regenerate_id() is used.

Thanks.

I've inspected my code and am only finding calls to session_start(), no session_regenerate_id().  I'll continue to test with the newer releases of PHP7.2 and report back if the issue re-occurs.

Glad to hear the second set of crashes are not due to the string interning problem.  Thanks for looking into all of this @ab.

@ab - just a final follow up.  I have been using 7.2 beta2 for the last week.

I have not seen the session related crash once.  With alpha3, I was seeing it 3 or 4 times a week.  So from my point of view the issue is fixed.

Also, I've seen no occurences of the original persistent string corruption issue.  As was the case with alpha2/3 of course.

Thanks to all for sorting these issues out.

Thanks for the continuous checks, @mike :)