shivammathur/homebrew-php

Segmentation fault with gettext functions (Ventura, PHP 8.2.8, Apple M1 and Intel)

picov opened this issue · 19 comments

picov commented

`
Describe the bug
PHP works except for pages that contains gettext functions.

PHP versions
8.2.8 (also with 7.4)

To Reproduce

<?php
if (function_exists("_")) {
	echo "GETTEXT IS AVAILABLE!<br>";
	$s=_("string"); // <- segmentation fault
}

I've tried to reinstall homebrew from scratch with no luck.

UPDATE:
I can confirm that the problem is not Apple M1 specific.
I've just done a brew update and brew upgrade on an Intel Mac that worked perfectly with gettext (PHP 8.2.7 and other old packages as deps was installed) and after the full upgrade the problem appears.

Error log:
[Thu Jul 27 08:25:45.217193 2023] [core:notice] [pid 17508] AH00052: child pid 17511 exit signal Segmentation fault (11)

Console dump:

Translated Report (Full Report Below)

Process: httpd [1270]
Path: /opt/homebrew/*/httpd
Identifier: httpd
Version: ???
Code Type: ARM-64 (Native)
Parent Process: httpd [1265]
Responsible: httpd [1265]
User ID: 501

Date/Time: 2023-07-26 19:27:24.1495 +0200
OS Version: macOS 13.4.1 (22F770820d)
Report Version: 12
Anonymous UUID: 4433CAA0-BF76-E312-9F89-D303F03DC9E2

Time Awake Since Boot: 530 seconds

System Integrity Protection: disabled

Crashed Thread: 0 Dispatch queue: com.apple.root.utility-qos

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000110
Exception Codes: 0x0000000000000001, 0x0000000000000110

VM Region Info: 0x110 is not in any region. Bytes before following region: 105553518919408
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
UNUSED SPACE AT START
--->
MALLOC_NANO (reserved) 600018000000-600020000000 [128.0M] rw-/rwx SM=NUL ...(unallocated)

Application Specific Information:
*** multi-threaded process forked ***
crashed on child side of fork pre-exec

Kernel Triage:
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage

Thread 0 Crashed:: Dispatch queue: com.apple.root.utility-qos
0 libdispatch.dylib 0x18657483c _dispatch_apply_with_attr_f + 1164
1 libdispatch.dylib 0x186574a38 dispatch_apply + 96
2 CoreFoundation 0x1869173cc __103-[CFPrefsSearchListSource synchronouslySendSystemMessage:andUserMessage:andDirectMessage:replyHandler:]_block_invoke.52 + 132
3 CoreFoundation 0x1867a4460 CFPREFERENCES_IS_WAITING_FOR_SYSTEM_AND_USER_CFPREFSDS + 100
4 CoreFoundation 0x1869165fc -[CFPrefsSearchListSource synchronouslySendSystemMessage:andUserMessage:andDirectMessage:replyHandler:] + 232
5 CoreFoundation 0x1867a2b80 -[CFPrefsSearchListSource alreadylocked_generationCountFromListOfSources:count:] + 232
6 CoreFoundation 0x1867a288c -[CFPrefsSearchListSource alreadylocked_getDictionary:] + 468
7 CoreFoundation 0x1867a2410 -[CFPrefsSearchListSource alreadylocked_copyValueForKey:] + 172
8 CoreFoundation 0x1867a2344 -[CFPrefsSource copyValueForKey:] + 52
9 CoreFoundation 0x1867a22f8 __76-[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:]_block_invoke + 32
10 CoreFoundation 0x18679b260 __108-[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:cloudConfigurationURL:perform:]_block_invoke + 376
11 CoreFoundation 0x186917c78 -[_CFXPreferences withSearchListForIdentifier:container:cloudConfigurationURL:perform:] + 384
12 CoreFoundation 0x18679ab30 -[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:] + 168
13 CoreFoundation 0x18679aa4c _CFPreferencesCopyAppValueWithContainerAndConfiguration + 112
14 libintl.8.dylib 0x100b3cca4 _nl_locale_name_default + 72
15 libintl.8.dylib 0x100b3af54 libintl_dcigettext + 1852
16 libphp.so 0x101a0f9f0 zif_gettext + 84
17 libphp.so 0x101d07d04 ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER + 84
18 libphp.so 0x101cc9a70 execute_ex + 52
19 libphp.so 0x101cc9c6c zend_execute + 288
20 libphp.so 0x101ca9fe4 zend_execute_scripts + 156
21 libphp.so 0x101c4fd94 php_execute_script + 460
22 libphp.so 0x101d8efac php_handler + 1024
23 httpd 0x100662414 ap_run_handler + 64
24 httpd 0x100662aec ap_invoke_handler + 264
25 httpd 0x100699eb4 ap_process_async_request + 792
26 httpd 0x100699f64 ap_process_request + 24
27 httpd 0x100696dc8 ap_process_http_connection + 344
28 httpd 0x1006738ac ap_run_process_connection + 64
29 mod_mpm_prefork.so 0x10087e3ec child_main + 1092
30 mod_mpm_prefork.so 0x10087de74 make_child + 436
31 mod_mpm_prefork.so 0x10087ded4 startup_children + 96
32 mod_mpm_prefork.so 0x10087d1ec prefork_run + 324
33 httpd 0x100675fbc ap_run_mpm + 84
34 httpd 0x100669500 main + 2200
35 dyld 0x1863b7f28 start + 2236

Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x0000000139e05ff0 x1: 0x0000000000000001 x2: 0x0000000000000001 x3: 0x0000000000000004
x4: 0x00000001869173f4 x5: 0x0000000000000001 x6: 0x0000000139e04390 x7: 0x0000000000000130
x8: 0x0000000000000100 x9: 0x0000000000000303 x10: 0x0000000018922220 x11: 0x0000000008922220
x12: 0x0000000008922220 x13: 0x0000000018922220 x14: 0x00000000ffffffff x15: 0x00000001e16ebda0
x16: 0x0000000186573e3c x17: 0x00000001e3457368 x18: 0x0000000000000000 x19: 0x00000001e16edc80
x20: 0x0000000000000000 x21: 0x0000000139e05ff0 x22: 0x00000000100004ff x23: 0x00006000022586c0
x24: 0x0000000139e05ff0 x25: 0x0000000000000104 x26: 0x00000001e16e9ee0 x27: 0x00000001e16e9f80
x28: 0x0000000000000001 fp: 0x000000016f7a2230 lr: 0xfb1a000186574814
sp: 0x000000016f7a2180 pc: 0x000000018657483c cpsr: 0x60001000
far: 0x0000000000000110 esr: 0x56000080 Address size fault

.....

kkthxx commented

Same issue with PHP 7.2.34_9 , Monterey.

Saeven commented

I encountered a similar problem in the homebrew-core project, see this link:
Homebrew/homebrew-core#137431 (comment)

I've tried those fpm parameters with php@7.4 and it seems to solve the issues.

@Saeven
If Homebrew decides to add the env parameter OBJC_DISABLE_INITIALIZE_FORK_SAFETY to the plist in the php formulae, I will add it here as well.

But, it would be great if we had a patch in php itself for this as from what I understand the env parameter just removes the safety check and does not solve the actual issue in the language.
php/php-src#11818

Saeven commented

@shivammathur for sure - just wanted to share a related finding. There were no updates beyond the report 👍🏻

askdkc commented

@picov @kkthxx

Could you please check if Homebrew/homebrew-core#137431 (comment) work around works for your environment?

You seem to using httpd(apache) with php-fpm. I found my work around works with nginx, and researching if it works on httpd. Thanks!

Hi folks,

This is still dying horribly for me on a regular basis withi all versions of PHP, and both with mod_php and Apache2, and witih nginx under php-fpm.

I've managed to generate some coredumps with nginx + php-fpm using the 8.1-debug package and PHP 8.1.22.

Here's the backtrace:

(lldb) bt
* thread #1, stop reason = ESR_EC_DABORT_EL0 (fault address: 0x110)
  * frame #0: 0x00000001908dc83c libdispatch.dylib`_dispatch_apply_with_attr_f + 1164
    frame #1: 0x00000001908dca38 libdispatch.dylib`dispatch_apply + 96
    frame #2: 0x0000000190c7f3cc CoreFoundation`__103-[CFPrefsSearchListSource synchronouslySendSystemMessage:andUserMessage:andDirectMessage:replyHandler:]_block_invoke.52 + 132
    frame #3: 0x0000000190b0c460 CoreFoundation`CFPREFERENCES_IS_WAITING_FOR_SYSTEM_AND_USER_CFPREFSDS + 100
    frame #4: 0x0000000190c7e5fc CoreFoundation`-[CFPrefsSearchListSource synchronouslySendSystemMessage:andUserMessage:andDirectMessage:replyHandler:] + 232
    frame #5: 0x0000000190b0ab80 CoreFoundation`-[CFPrefsSearchListSource alreadylocked_generationCountFromListOfSources:count:] + 232
    frame #6: 0x0000000190b0a88c CoreFoundation`-[CFPrefsSearchListSource alreadylocked_getDictionary:] + 468
    frame #7: 0x0000000190b0a410 CoreFoundation`-[CFPrefsSearchListSource alreadylocked_copyValueForKey:] + 172
    frame #8: 0x0000000190b0a344 CoreFoundation`-[CFPrefsSource copyValueForKey:] + 52
    frame #9: 0x0000000190b0a2f8 CoreFoundation`__76-[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:]_block_invoke + 32
    frame #10: 0x0000000190b03260 CoreFoundation`__108-[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:cloudConfigurationURL:perform:]_block_invoke + 376
    frame #11: 0x0000000190c7fc78 CoreFoundation`-[_CFXPreferences withSearchListForIdentifier:container:cloudConfigurationURL:perform:] + 384
    frame #12: 0x0000000190b02b30 CoreFoundation`-[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:] + 168
    frame #13: 0x0000000190b02a4c CoreFoundation`_CFPreferencesCopyAppValueWithContainerAndConfiguration + 112
    frame #14: 0x000000019e3219f4 Heimdal`init_context_from_config_file + 2932
    frame #15: 0x000000019e306178 Heimdal`krb5_set_config_files + 440
    frame #16: 0x000000019e3059f8 Heimdal`krb5_init_context_flags + 348
    frame #17: 0x000000019e305890 Heimdal`krb5_init_context + 32
    frame #18: 0x00000001a06b5330 Kerberos`mshim_ctx + 64
    frame #19: 0x00000001a06b3720 Kerberos`context_new_ccache_iterator + 92
    frame #20: 0x00000001045ac4c8 libkrb5.3.3.dylib`api_macos_ptcursor_next + 220
    frame #21: 0x00000001045a9788 libkrb5.3.3.dylib`krb5_cccol_cursor_next + 76
    frame #22: 0x00000001045a9a70 libkrb5.3.3.dylib`krb5_cccol_have_content + 92
    frame #23: 0x0000000104411894 libgssapi_krb5.2.2.dylib`acquire_cred_context + 1664
    frame #24: 0x000000010441119c libgssapi_krb5.2.2.dylib`acquire_cred_from + 688
    frame #25: 0x0000000104403180 libgssapi_krb5.2.2.dylib`gss_add_cred_from + 624
    frame #26: 0x0000000104402dc8 libgssapi_krb5.2.2.dylib`gss_acquire_cred_from + 400
    frame #27: 0x0000000104402c2c libgssapi_krb5.2.2.dylib`gss_acquire_cred + 36
    frame #28: 0x000000010410aa4c libpq.5.15.dylib`pg_GSS_have_cred_cache + 60
    frame #29: 0x00000001040f9be4 libpq.5.15.dylib`PQconnectPoll + 4500
    frame #30: 0x00000001040f7464 libpq.5.15.dylib`connectDBComplete + 300
    frame #31: 0x00000001040f75d0 libpq.5.15.dylib`PQconnectdb + 44
    frame #32: 0x0000000103174ba0 php-fpm`php_pgsql_do_connect + 748
    frame #33: 0x0000000106151924 xdebug.so`xdebug_execute_internal + 740
    frame #34: 0x00000001033b5500 php-fpm`ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER + 248
    frame #35: 0x0000000103390538 php-fpm`execute_ex + 48
    frame #36: 0x0000000106151494 xdebug.so`xdebug_execute_ex + 1808
    frame #37: 0x00000001033b5278 php-fpm`ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER + 416
    frame #38: 0x0000000103390538 php-fpm`execute_ex + 48
    frame #39: 0x0000000106151494 xdebug.so`xdebug_execute_ex + 1808
    frame #40: 0x00000001033b5278 php-fpm`ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER + 416
    frame #41: 0x0000000103390538 php-fpm`execute_ex + 48
    frame #42: 0x0000000106151494 xdebug.so`xdebug_execute_ex + 1808
    frame #43: 0x00000001033b5278 php-fpm`ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER + 416
    frame #44: 0x0000000103390538 php-fpm`execute_ex + 48
    frame #45: 0x0000000106151494 xdebug.so`xdebug_execute_ex + 1808
    frame #46: 0x00000001033b5278 php-fpm`ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER + 416
    frame #47: 0x0000000103390538 php-fpm`execute_ex + 48
    frame #48: 0x0000000106151494 xdebug.so`xdebug_execute_ex + 1808
    frame #49: 0x00000001033bb01c php-fpm`ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER + 608
    frame #50: 0x0000000103390538 php-fpm`execute_ex + 48
    frame #51: 0x0000000106151494 xdebug.so`xdebug_execute_ex + 1808
    frame #52: 0x00000001033bb01c php-fpm`ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER + 608
    frame #53: 0x0000000103390538 php-fpm`execute_ex + 48
    frame #54: 0x0000000106151494 xdebug.so`xdebug_execute_ex + 1808
    frame #55: 0x0000000103390734 php-fpm`zend_execute + 296
    frame #56: 0x0000000103372950 php-fpm`zend_execute_scripts + 168
    frame #57: 0x00000001033129f0 php-fpm`php_execute_script + 484
    frame #58: 0x0000000103467e30 php-fpm`main + 6128
    frame #59: 0x000000019071ff28 dyld`start + 2236
(lldb)

This does happen with xdebug disabled too.

I have applied th OBJC workaround to the plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>EnvironmentVariables</key>
  <dict>
      <key>OBJC_DISABLE_INITIALIZE_FORK_SAFETY</key>
      <string>YES</string>
  </dict>
	<key>KeepAlive</key>
	<true/>
	<key>Label</key>
	<string>homebrew.mxcl.php@8.1-debug</string>
	<key>LimitLoadToSessionType</key>
	<array>
		<string>Aqua</string>
		<string>Background</string>
		<string>LoginWindow</string>
		<string>StandardIO</string>
		<string>System</string>
	</array>
	<key>ProgramArguments</key>
	<array>
		<string>/opt/homebrew/opt/php@8.1-debug/sbin/php-fpm</string>
		<string>--nodaemonize</string>
	</array>
	<key>RunAtLoad</key>
	<true/>
	<key>StandardErrorPath</key>
	<string>/opt/homebrew/var/log/php-fpm.log</string>
	<key>WorkingDirectory</key>
	<string>/opt/homebrew/var</string>
</dict>
</plist>

This has not helped in any noticable way.

Let me know if there's anything I can do to help, or more information I can provide. I know a number of my colleagues are hitting the same issue recently.

I got Same issue with PHP 7.4.33 , M1 Sonoma. And I just use the default config files.

I got Same issue with PHP 7.4.33 , M1 Sonoma. And I just use the default config files.

But I tried build php (7.4.33 and 8.2)locally, and it's working.

I'm still not sure what's the problem.

desoi commented

OBJC_DISABLE_INITIALIZE_FORK_SAFETY did not solve it for me, but setting LC_ALL seems to. Idea came from the link below. Added this to the homebrew.mxcl.httpd.plist EnvironmentVariables section:

<key>LC_ALL</key>
<string>en_US.UTF-8</string>

Homebrew/homebrew-core#137431 (comment)

Using Drupal 10 with Apache 2.4.58 and PHP 8.2.12 on macOS Ventura 13.6.

hoyhoy commented

Bash was crashing in for me in CFPrefsSearchListSource as well. export LC_ALL=en_US.UTF-8 worked for me. Nothing else did.

I have all of the following set in my .bash_login.

export LC_ALL=en_US.UTF-8
export PGGSSENCMODE=disable
export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES
launchctl setenv OBJC_DISABLE_INITIALIZE_FORK_SAFETY YES
hoyhoy commented

Actually, no it didn't fix the problem. Still getting the same stacktrace...

  * frame #0: 0x00007ff815d29e0f libsystem_trace.dylib`_os_log_preferences_refresh + 61
    frame #1: 0x00007ff815d2a72e libsystem_trace.dylib`os_log_type_enabled + 676
    frame #2: 0x00007ff8160605a9 CoreFoundation`-[CFPrefsSearchListSource alreadylocked_copyValueForKey:] + 181
    frame #3: 0x00007ff8160604d8 CoreFoundation`-[CFPrefsSource copyValueForKey:] + 47
    frame #4: 0x00007ff816060490 CoreFoundation`__76-[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:]_block_invoke + 32
    frame #5: 0x00007ff8160590fa CoreFoundation`__108-[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:cloudConfigurationURL:perform:]_block_invoke + 360
    frame #6: 0x00007ff8161cabf0 CoreFoundation`-[_CFXPreferences withSearchListForIdentifier:container:cloudConfigurationURL:perform:] + 349
    frame #7: 0x00007ff816058b32 CoreFoundation`-[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:] + 124
    frame #8: 0x00007ff816058a78 CoreFoundation`_CFPreferencesCopyAppValueWithContainerAndConfiguration + 101
    frame #9: 0x00007ff817265410 Foundation`$s10Foundation11LocaleCacheV18preferredLanguages14forCurrentUserSaySSGSb_tFTf4nd_n + 112
    frame #10: 0x00007ff81744c12f Foundation`$sSo8NSLocaleC10FoundationE33_preferredLanguagesForCurrentUser33_9CF57171D9878F97AD4FAD15D782DF7FLLySaySSGSbFZTo + 31
    frame #11: 0x00007ff8160a77d4 CoreFoundation`CFLocaleCopyPreferredLanguages + 26
    frame #12: 0x0000000104dbe524 libintl.8.dylib`_nl_language_preferences_default + 52
    frame #13: 0x0000000104dbc3b2 libintl.8.dylib`libintl_dcigettext + 674
    frame #14: 0x0000000104c6366d bash`execute_disk_command + 685
    frame #15: 0x0000000104c5e639 bash`execute_simple_command + 3817
    frame #16: 0x0000000104c5c442 bash`execute_command_internal + 3090
    frame #17: 0x0000000104c5b7c4 bash`execute_command + 116
    frame #18: 0x0000000104c491e6 bash`reader_loop + 774
    frame #19: 0x0000000104c47b5f bash`main + 5007
    frame #20: 0x00007ff815c473a6 dyld`start + 1942
desoi commented

After the LC_ALL change, my web server ran for 10 days without a single error. But then the PHP segmentation fault errors started showing up again in increasing numbers. Only solution so far is to restart the httpd process.

Without the LC_ALL change, I can 100% reliably crash using the code in the first message of the the thread. It must be something additional beyond that.

[Thu Nov 16 14:04:04.566816 2023] [core:notice] [pid 89945] AH00052: child pid 6532 exit signal Segmentation fault (11)
[Thu Nov 16 23:09:13.882717 2023] [core:notice] [pid 89945] AH00052: child pid 36883 exit signal Segmentation fault (11)
[Fri Nov 17 08:40:32.227542 2023] [core:notice] [pid 89945] AH00052: child pid 67848 exit signal Segmentation fault (11)

hoyhoy commented

This seems to be a problem with macOS's CoreFoundation (or maybe how autoconf builds the source). What finally solved this for me was configuring bash with --disable-nls. I had to modify the bash source to get this to work as well because the latest version of bash doesn't even compile with nls disabled.

What I see during the bash configure is that autoconf is emitting HAVE_CFPREFERENCESCOPYAPPVALUE. Autoconf is also emitting some CFPreferencesCopyAppValue macros to the m4 scripts, but only to check that the symbol exists. The weird thing is, bash doesn't call CFPreferencesCopyAppValue() itself. It seems to be getting called from gettext's libintl_dcigettext().

My guess is that something in macOS CoreFoundation changed about 18 months ago because that's when this started happening for me.

hoyhoy commented

Just found this comment from ten years ago...
In particular, the bug happens if LC_ALL, LC_MESSAGES and LANG are all not set and 'gettext' is called for the first time in a child process (because otherwise CFPreferencesCopyAppValue is not called as the result is cached). See

hoyhoy commented

Just re-re-re-compiled bash with nls enabled and this worked...

export LC_ALL=C
export LC=C
export LANG=C
export LC_MESSAGES=C
drbyte commented

Just re-re-re-compiled bash with nls enabled and this worked...

export LC_ALL=C
export LC=C
export LANG=C
export LC_MESSAGES=C

Take note: PHP has decided that the longstanding default locale of 'C' (which basically means "unconfigured" on this host) is invalid and now throws an exception if an actual locale has not been defined in PHP. Starting with PHP 8.3.0
So, give consideration to the defaults you choose to compile or configure with.

hoyhoy commented

Take note: [PHP has decided that the longstanding default locale of 'C'

Any value from locale -a will work as long as they're the same. Apparently this is some ten-year-old bug with autoconf, gettext, and CoreFramework. Seemed to start manifesting segfaults for me two years ago though...

LC_ALL=en_US.UTF-8
LC=en_US.UTF-8
LANG=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
desoi commented

My website is still crashing in CFPrefsSearchListSource, but there is a second source beyond gettext. homebrew's PostgreSQL builds use buggy Apple Kerberos/Heimdal libraries. PHP is randomly crashing when connecting to a database because of the same forking issue. OBJC_DISABLE_INITIALIZE_FORK_SAFETY does not help. See details here:

https://www.postgresql.org/message-id/flat/0100018c20b152e0-ec85ac20-b379-46d7-a962-c59e00f3201c-000000%40email.amazonses.com

desoi commented

Finally resolved by setting PGGSSENCMODE=disable.