php55-opcache, php56-opcache: crash when built with Xcode 10

[hostep (Pieter Hoste)]

Hi

Today I finally decided to upgrade to macOS Mojave and re-install all the ports I need.

I still have to support various projects running on PHP 5.5 unfortunately, and I noticed it no longer properly works on Mojave when php55-opcache is installed and enabled.

My setup is with Apache 2.4 => php55-fpm => php scripts
CLI-wise, everything is fine. But when attempting to open a php script through the webserver, it crashes.

The php-fpm.log says

[23-Feb-2019 18:27:19] WARNING: [pool www] child 95563 exited on signal 11 (SIGSEGV) after 3.393581 seconds from start

Here's part of a crash log I found in /Library/DiagnosticReports:

Process:               php-fpm55 [95562]
Path:                  /opt/local/sbin/php-fpm55
Identifier:            php-fpm55
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        php-fpm55 [95553]
Responsible:           php-fpm55 [95562]
User ID:               501

Date/Time:             2019-02-23 18:58:28.405 +0100
OS Version:            Mac OS X 10.14.3 (18D109)
Report Version:        12
Bridge OS Version:     3.0 (14Y674)


Time Awake Since Boot: 8300 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000208d2385b
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [95562]

VM Regions Near 0x208d2385b:
    VM_ALLOCATE            0000000115ee4000-0000000155ee4000 [  1.0G] rw-/rwx SM=ALI  
--> 
    MALLOC_TINY            00007f9cb5400000-00007f9cb5800000 [ 4096K] rw-/rwx SM=COW  

Application Specific Information:
crashed on child side of fork pre-exec

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   opcache.so                      0x000000010d8399b4 zend_block_optimization + 13144
1   opcache.so                      0x000000010d835912 zend_optimizer + 6753
2   php-fpm55                       0x000000010b1556e4 zend_llist_apply_with_argument + 31
3   php-fpm55                       0x000000010b1565c4 pass_two + 581
4   php-fpm55                       0x000000010b12e20c compile_file + 316
5   php-fpm55                       0x000000010b03b88c phar_compile_file + 268
6   xdebug.so                       0x000000010d7f91b3 xdebug_compile_file + 12
7   opcache.so                      0x000000010d82a0f3 compile_and_cache_file + 617
8   opcache.so                      0x000000010d829c4f persistent_compile_file + 1849
9   php-fpm55                       0x000000010b15f1b6 zend_execute_scripts + 327
10  php-fpm55                       0x000000010b10bb3e php_execute_script + 633
11  php-fpm55                       0x000000010b1efd38 main + 6157
12  libdyld.dylib                   0x00007fff6df98ed9 start + 1

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x00000000ffffff80  rbx: 0x0000000110d23fa8  rcx: 0x0000000208d2385b  rdx: 0x0000000000000004
  rdi: 0x0000000110d24278  rsi: 0x00000000f8000003  rbp: 0x00007ffee4c57d70  rsp: 0x00007ffee4c57c80
   r8: 0x0000000110d23890   r9: 0x0000001fffffffe0  r10: 0x0000000000000203  r11: 0x00000000000000a1
  r12: 0x0000000110d23858  r13: 0x0000000000000013  r14: 0x0000000110d22608  r15: 0x0000000110d27b28
  rip: 0x000000010d8399b4  rfl: 0x0000000000010206  cr2: 0x0000000208d2385b

It appears this is a know problem in Homebrew and FreeBSD and already got fixed in those projects:

• ​http://openbsd-archive.7691.n7.nabble.com/clang-6-php-5-6-broken-with-opcache-td341170.html & ​https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227723
• ​https://github.com/Homebrew/homebrew-core/issues/32434 (fix: ​https://github.com/Homebrew/homebrew-core/commit/67cdb1180bf7aaddf7a22135f5fc9011964b783f)

I have this problem on PHP 5.5, but it might as well occur on 5.6 or 5.4 and 5.3 (I haven't tested these). On PHP 7.0, 7.1 and 7.2 it does not occur.

Any chance a fix can be included in Macports for this problem?

I would totally understand if this gets closed without resolution, as PHP 5.x is no longer supported.
We can work around the problem by disabling the opcache module in PHP. Just posting this to see if there is interest or maybe for other people who run against the same problem so they can find a solution quicker.

Thanks!

[ryandesign (Ryan Carsten Schmidt)]

Thanks for reporting this problem and the solution that others are using.

I can confirm the problem on High Sierra with the Apache 2 handler using PHP 5.5 and 5.6 when opcache is compiled with MacPorts clang 7.0 (and presumably 6.0, according to the other reports) and I can confirm that the proposed patch fixes it. I don't see the problem when opcache is compiled using the clang in Xcode 9.4.1, but presumably I would see the problem if I upgraded to Xcode 10. PHP 5.4 and earlier and 7.0 and later don't seem to be affected.

I'll get it fixed in MacPorts, but it would be a good idea to report this problem to the developers of PHP so that if they do make another release of the 5.6 branch they can include this fix. Would you report it to them?

[ryandesign (Ryan Carsten Schmidt)]

In 6223b017e474c9bdcda958c618553136c681da8d/macports-ports (master):

php: Fix php-opcache when compiled with clang 6+

Closes: #58119

[hostep (Pieter Hoste)]

Thank you for this very quick fix Ryan!

I can confirm that updating to the latest version of php55 & php55-opcache in my case fixes the issue.

As for reporting the issue to PHP maintainers, I'm afraid we are too late for that, since PHP version 5.6 is no longer supported since 31 Dec 2018: ​http://php.net/supported-versions.php

Thanks again!

[ryandesign (Ryan Carsten Schmidt)]

Glad to hear it worked for you too!

I know that 5.6 is no longer supported since December 2018. That didn't stop them from ​releasing 5.6.40 in January 2019 with the note "There may be additional release if we discover important security issues that warrant it". But if they don't know about this problem, they certainly won't include a fix for it in such a possible future release. So I would recommend reporting it to them so they have the option of fixing it.