Repository navigation
php 8.1 and earlier crash immediately when compiled with Xcode 16 clang on macOS 15 #16168
Description
Description
Hi, I'm the maintainer of php in MacPorts. macOS 15 and Xcode 16 were recently released, and following a user report, I discovered that php 8.1 and earlier crash when compiled there. php 8.2 and later don't have this problem, so I'm hoping to discover what change in php 8.2 fixed this so that I can backport it to earlier versions.
The crash is observed during installation:
Generating phar.php
/bin/sh: line 1: 55243 Segmentation fault
For php 8.1, this crash is ignored and the installation process continues, but the installed executable crashes when trying to do anything (php, php -v, etc.). For php 8.0 and earlier, the crash stops the installation process.
From the MacPorts ticket, I've seen two different crash logs—one a segmentation fault with no backtrace showing that execution has passed to an illegal address 0x1e8:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000000001e8
Exception Codes: 0x0000000000000001, 0x00000000000001e8
Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process: exc handler [75775]
VM Region Info: 0x1e8 is not in any region. Bytes before following region: 4509498904
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
__TEXT 10cc98000-10d683000 [ 9.9M] r-x/r-x SM=COW /opt/local/var/macports/*/php
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 ??? 0x1e8 ???
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x00007fd29780c900 rbx: 0x000000010e205000 rcx: 0x0000000000000003 rdx: 0x000000010e205020
rdi: 0x000000010e205000 rsi: 0x000000010e200000 rbp: 0x000000000000001a rsp: 0x00007ff7b3266be0
r8: 0x000000010e205000 r9: 0x000000000000006c r10: 0x00000000001ff800 r11: 0x0000000000000030
r12: 0x0000000000000000 r13: 0x000000010d6989c0 r14: 0x00007ff7b3266c00 r15: 0x000000010ce78ecd
rip: 0x00000000000001e8 rfl: 0x0000000000010202 cr2: 0x00000000000001e8
Logical CPU: 0
Error Code: 0x00000014 (no mapping for user instruction read)
Trap Number: 14
and the other an abort trap implicating an unnamed (inline?) function called from zend_hash_find:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process: php [40488]
Application Specific Information:
abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x7ff813d7db52 __pthread_kill + 10
1 libsystem_pthread.dylib 0x7ff813db7f85 pthread_kill + 262
2 libsystem_c.dylib 0x7ff813cd8b19 abort + 126
3 libsystem_malloc.dylib 0x7ff813bd7ab1 malloc_vreport + 857
4 libsystem_malloc.dylib 0x7ff813bdb58b malloc_report + 151
5 php 0x10cf5e27d .LL31 + 203
6 php 0x10cef6498 zend_hash_find + 128
7 php 0x10cf752b1 lookup_class_ex + 312
8 php 0x10cf70823 zend_perform_covariant_type_check + 885
9 php 0x10cf75ae8 zend_do_perform_implementation_check + 554
10 php 0x10cf755f8 do_inheritance_check_on_method + 344
11 php 0x10cf722df do_interface_implementation + 520
12 php 0x10ceec276 zend_class_implements + 216
13 php 0x10cf5d6fd zend_register_weakref_ce + 316
14 php 0x10cf703be zend_register_default_classes + 34
15 php 0x10cef7ba5 zm_startup_core + 101
16 php 0x10cee9ff9 zend_startup_module_ex + 259
17 php 0x10ceea38f zend_startup_module_zval + 12
18 php 0x10cef55cd zend_hash_apply + 87
19 php 0x10ce87a9c php_module_startup + 2180
20 php 0x10cfbb90d php_cli_startup + 13
21 php 0x10cfb9666 main + 1356
22 dyld 0x7ff813a2a2cd start + 1805
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000000000006 rcx: 0x00007ff7b3203dc8 rdx: 0x0000000000000000
rdi: 0x0000000000000103 rsi: 0x0000000000000006 rbp: 0x00007ff7b3203df0 rsp: 0x00007ff7b3203dc8
r8: 0x000000000000002e r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000246
r12: 0x0000000000000000 r13: 0x0000000000000050 r14: 0x0000000000000103 r15: 0x0000000000000016
rip: 0x00007ff813d7db52 rfl: 0x0000000000000246 cr2: 0x0000000000000000
Logical CPU: 0
Error Code: 0x02000148
Trap Number: 133
On one machine, running php produced this possibly helpful diagnostic:
php(54330,0x7ff8522ffbc0) malloc: *** error for object 0x2cf607000: pointer being freed was not allocated
php(54330,0x7ff8522ffbc0) malloc: *** set a breakpoint in malloc_error_break to debug
PHP Version
8.1.30
Operating System
macOS 15.0
Activity
cmb69 commentedon Oct 2, 2024
I assume that you don't have this environment; otherwise a
git bisectshould find the commit(s).The first issue might be related to OPcache JIT.
iluuu1994 commentedon Oct 2, 2024
I ran a quick test-build in CI but couldn't reproduce the issue: https://github.com/iluuu1994/php-src/actions/runs/11144438755/job/30971704251 (ignore the failing last step)
A bisect would indeed be helpful. Usually, opcache is disabled in CLI by default, and JIT is disabled entirely. It also seems to occur during startup.
@ryandesign Are these debug builds? If not, can you try that? As usual, ASan/UBSan would be useful. Also, is this a problem that only appeared on macOS 15.0? This sounds like a compiler issue.
I don't have a Mac, but I think @kocsismate and @devnexen do. They might be able to help.
kocsismate commentedon Oct 2, 2024
I still have MacOS 14.4, so I check also check what happens before and after an upgrade 😎
ryandesign commentedon Oct 2, 2024
I have reproduced the issue locally on a 13-year-old dual core machine but before I have it spend a day bisecting I thought I'd ask if the issue is familiar to anyone.
They are not. I can try that.
I don't know what that is.
So far I am only aware of the issue occurring with macOS 15.0 + Xcode 16.0, not on earlier macOS versions with earlier Xcode versions. Xcode 16.0 is also compatible with macOS 14 ≥ 14.5 but I have not tested whether the issue occurs then. I could not say at this point whether the defect is in the compiler, the OS, or php's code.
kocsismate commentedon Oct 2, 2024
I also managed to reproduce the issue with a debug build + ASAN, running on MacOS 14.4 + XCode 16:
Apparently, PCRE2 Lib is to blame... And I guess the difference between PHP 8.1- and PHP 8.2+ is Christoph's commit: kocsismate@32cceb7 that updated the library.
iluuu1994 commentedon Oct 2, 2024
@kocsismate Do you get no errors with
--without-pcre-jit? If so, Ryan might try the same.kocsismate commentedon Oct 3, 2024
@iluuu1994 I have several extensions enabled, but I don't hava errors anymore.
ryandesign commentedon Oct 3, 2024
Based on the filename I assume this is arm64 code. My tests were on x86_64 so the problem is at least not specific to arm64.
For php in MacPorts we use MacPorts pcre2, not the pcre2 bundled with php—at least that's what I intend for it to do. At least looking at the library linkage, it appears to have been successful:
All MacPorts php versions from php73 onward link with the same MacPorts pcre2 library, so that would not appear to explain why php82 and later work and php81 and earlier don't, unless php still uses part of its bundled pcre2 even when told to use an external pcre2.
MacPorts pcre2 is built configured with
--enable-jit. Rebuilding it with--disable-jitcauses all of the php versions—both those that crashed before and those that worked—to fail with the same error:I have not yet tried rebuilding any of the phps with the JITless pcre2 nor have I tried php's
--without-pcre-jitconfigure option.cmb69 commentedon Oct 3, 2024
@kocsismate, ASan may report false positives for PCRE JIT code.
NattyNarwhal commentedon Oct 3, 2024
FWIW, I can't seem to reproduce this on my system (M1 Pro, macOS 14.7, Xcode 16, MacPorts). Were you using a specific set of ./configure options?
ryandesign commentedon Oct 3, 2024
Yes I also had problems reproducing this when trying to run
git bisectdoing builds outside of MacPorts until I added in configure options that are used in MacPorts.I was initially using these flags and could not reproduce the problem:
I'm now reproducing the problem using:
I have not tried to figure out which of those flags make the problem appear because it takes so very long for this old machine to build php.
ryandesign commentedon Oct 3, 2024
Also I am setting
CFLAGS="-Os -Wno-error=implicit-function-declaration -Wno-error=implicit-int -Wno-error=incompatible-function-pointer-types -Wno-error=int-conversion". I tried--enable-debuginitially but when I couldn't reproduce the problem I noticed it was setting-O0so I removed it, thinking that might be hiding the problem. I used-Osbecause that is what MacPorts uses. After that, I found that I needed to add the additional configure flags mentioned above to reproduce the problem.I found a faster machine to run
git bisecton and it identified 6339938 as the commit that fixed the problem.51 remaining items
66Ton99 commentedon Dec 7, 2024
Now is next month were if the fix?
iluuu1994 commentedon Dec 7, 2024
@66Ton99 8.4.1, 8.3.14 and 8.2.26. Maybe MacPorts has not updated to the new version yet. Or you're on <=8.1, which does not receive non-security patches.
ndossche commentedon Dec 7, 2024
@iluuu1994 Similarly to how we backported libxml fixes to get the build going again on macos, perhaps this can be backported with RM permission too, wdyt?
iluuu1994 commentedon Dec 7, 2024
@nielsdos Yeah, compile issues make sense to backport IMO. But of course, RMs have the final word.
ndossche commentedon Dec 7, 2024
cc @ramsey @patrickallaert The patch for this issue resolves breakage on modern compiler macOS toolchain on PHP 8.1. Are there any objections in backporting #16348 to 8.1 such that the next security release contains that patch too?
ramsey commentedon Dec 8, 2024
I have no objections to backporting #16348 to 8.1.
Backport GH-16348
ndossche commentedon Dec 9, 2024
Backported via 806d2e0, only required a trivial merge conflict resolution
Update GitHub Actions: Replace deprecated macOS 13 with macOS 15-intel