php73: can throw a known bus error on freebsd flavored OS if using ifuncs, can fix in configure.ac

[johnww2]

PHP 7.3.6 apparently has this known issue with ifunc usage on freebsd flavored platforms fixed in later version than available on MacPorts per this;

I'm no expert on that but I can follow along in the home game by understanding the basic fix...

​https://github.com/php/php-src/commit/291589114aa9be899cf7d5d874c3b5bbdb35f336#diff-67e997bcfdac55191033d57a16d1408a

I encountered this php issue in the course of using laravel

STEPS TO REPRODUCE

0. Mojave 10.14.5
1. MacPorts clean install with requested per below
2. install laravel (​https://laravel.com)
3. set up laravel and make a new site per laravel docs (implying apache, openssl, database backend etc.)
4. access the site (fails to load) (I'm using localhost as my domain)
5. see log files per below indicating bus error / problem in mod_php73.so
6. per above github commit, create a patch for php's config.ac file adding darwin to list of hosts that will not use ifuncs

CONFIRMED FIXED by making patch, and reinstalling php77 from customized php local port per

wiki:howto/PatchLocal

patch assembled per github fix reference above (adding darwin) ....

--- a/configure.ac.orig	2019-06-14 14:32:23.000000000 +0900
+++ b/configure.ac	2019-06-14 14:29:02.000000000 +0900
@@ -606,7 +606,7 @@
 dnl
 dnl At least some versions of FreeBSD seem to have buggy ifunc support, see
 dnl bug #77284. Conservatively don't use ifuncs on FreeBSD.
-AS_CASE([$host_alias], [*-*-*android*|*-*-*uclibc*|*-*-*musl*|*freebsd*], [true], [
+AS_CASE([$host_alias], [*-*-*android*|*-*-*uclibc*|*-*-*musl*|*freebsd*][*-*-darwin*], [true], [
   AX_GCC_FUNC_ATTRIBUTE([ifunc])
   AX_GCC_FUNC_ATTRIBUTE([target])
 ])

additional config info when issue encountered...

ports requested...

apache2                        @2.4.39_0+preforkmpm 
mariadb-server                 @5.5.64_0 
mod_python                     @3.5.0_0 
mod_wsgi                       @4.6.5_0 
openssl                        @1.0.2s_0 
php73                          @7.3.6_0+libedit 
php73-apache2handler           @7.3.6_0 
php73-curl                     @7.3.6_0 
php73-iconv                    @7.3.6_0 
php73-imap                     @7.3.6_0 
php73-mbstring                 @7.3.6_0 
php73-mcrypt                   @1.0.2_0 
php73-memcached                @3.0.4_0 
php73-mysql                    @7.3.6_0+mysqlnd 
php73-opcache                  @7.3.6_0 
php73-openssl                  @7.3.6_0 
php73-redis                    @4.2.0_0 
php73-sqlite                   @7.3.6_0 
py36-tz                        @2018.9_0 
py37-pip                       @19.1.1_0 
py37-tkinter                   @3.7.3_0 
python36                       @3.6.8_0 
python37                       @3.7.3_0 
redis                          @5.0.5_0 

crash...

sudo tail -50 /opt/local/var/log/apache2/error_log

[Fri Jun 14 13:11:23.663560 2019] [core:notice] [pid 55208] AH00052: child pid 82569 exit signal Bus error (10)
[Fri Jun 14 13:11:23.664173 2019] [core:notice] [pid 55208] AH00052: child pid 82568 exit signal Bus error (10)
[Fri Jun 14 13:11:23.664201 2019] [core:notice] [pid 55208] AH00052: child pid 82565 exit signal Bus error (10)
[Fri Jun 14 13:11:24.665747 2019] [core:notice] [pid 55208] AH00052: child pid 82571 exit signal Bus error (10)
[Fri Jun 14 13:11:24.666209 2019] [core:notice] [pid 55208] AH00052: child pid 82567 exit signal Bus error (10)
[Fri Jun 14 13:11:24.666230 2019] [core:notice] [pid 55208] AH00052: child pid 82566 exit signal Bus error (10)

looking in Console.app at system reports for http...

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   ???                           	0x000000010cf20700 php_base64_encode + 0
1   mod_php73.so                  	0x000000010c82dee3 ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER + 80
2   mod_php73.so                  	0x000000010c7e6388 execute_ex + 98
3   mod_php73.so                  	0x000000010c7e6504 zend_execute + 318
4   mod_php73.so                  	0x000000010c7aaf86 zend_execute_scripts + 277
5   mod_php73.so                  	0x000000010c75647d php_execute_script + 655
6   mod_php73.so                  	0x000000010c8550a8 php_handler + 1045
7   httpd                         	0x000000010bc229ef ap_run_handler + 51
8   httpd                         	0x000000010bc22fa9 ap_invoke_handler + 240
9   httpd                         	0x000000010bc5816a ap_process_async_request + 859
10  httpd                         	0x000000010bc58201 ap_process_request + 20
11  httpd                         	0x000000010bc54e9b ap_process_http_connection + 301
12  httpd                         	0x000000010bc3304a ap_run_process_connection + 51
13  httpd                         	0x000000010bc5f80e child_main + 1088
14  httpd                         	0x000000010bc5f2ca make_child + 409
15  httpd                         	0x000000010bc5ecda prefork_run + 2120
16  httpd                         	0x000000010bc353bc ap_run_mpm + 64
17  httpd                         	0x000000010bc29e24 main + 2104
18  libdyld.dylib                 	0x00007fff7dbf53d5 start + 1

[ryandesign (Ryan Carsten Schmidt)]

Please remember to use WikiFormatting.

I've tried the two test scripts in ​https://bugs.php.net/bug.php?id=77284; they work fine for me with MacPorts php73 on macOS High Sierra. I haven't tested on Mojave.

[slaakso (Seppo Laaksonen)]

Looks like this bug also causes all calls to openssl_encrypt to fail with Mojave (10.14.5) + php73 @7.3.7_0+libedit + php73-openssl @7.3.7_0. The crash report is identical to johnww2's.

Code to repoduce:

<?php

$string = 'A21AAGKNBOtl07Vi9GhIH7Vq8U7Bo8lVouF2VOA8z-zcavwk0p-15NFTje6dVQNUYX3E8rUqdB78MncT2TwWdD_EQ_rk28DRQ';
$key = 'EPCSQhC3UGJm1NdsSpN_DCMHDGdEQJj_wAZiOhN0T4I9Kyi6Qx_ndfhr5Rhz';
$iv = '5d4becbdbd5b02.1';

$encrypted = openssl_encrypt($string, "AES-256-CBC", $key, 0, $iv);

Works ok in php72 @7.2.20_0+libedit

[ryandesign (Ryan Carsten Schmidt)]

Has anybody reported this problem to the developers of PHP? If not, please do, and provide a link to it here. They're not going to fix problems they don't know about.

[ryandesign (Ryan Carsten Schmidt)]

I still haven't been able to reproduce the problem, but I've been testing using php73 built from source on my computer. But it sounds like as of PHP 7.3, it's checking at configure time which SIMD technologies are present, which it will then use at runtime. So if you get a binary of php73 from our server, and our build server has more SIMD capabilities than your processor does, that won't work. And if that's so, then we should disable the use of SIMD technologies as suggested. Our build server runs on an Xserve (Late 2009) with a Nehalem processor, on which it detects the availability of ssse3 and sse4.2. So if your Mac has a processor that predates Nehalem (such as Core or Core 2), that could explain why it wouldn't work.

Collecting some more data would be helpful. To everyone experiencing the problem:

• Did you get php73 and php73-openssl from our build server or was it compiled on your computer?
• If you got a binary, does rebuilding from source help? (sudo port -ns upgrade --force php73 php73-openssl)
• What version number and build number of Xcode?
• What version number and build number of macOS?
• What Mac model name and year and CPU?
• Does the problem only occur in a web server environment or can you reproduce the problem using a command line PHP script?

[TheDigitalOrchard (The Digital Orchard)]

I saw a bus error when accessing my application via php at the command line. Via php-fpm, it was displaying a '502 Server Error`. I suspect both were the same crash happening at the moment openssl_* functions were being called.

The code that was affected in my application was identical to what comment:3 above has. If that code was never executed, the crash never occurred.

• macOS Mojave (fully updated), 2013 MacBook Air
• Xcode 10.3 (no space to upgrade) :)
• fresh installs of php packages from MacPorts
• nginx via MacPorts

The problem went away when I re-installed everything using the +debug variant, and I'm not sure why.

[ryandesign (Ryan Carsten Schmidt)]

Replying to TheDigitalOrchard:

• macOS Mojave (fully updated), 2013 MacBook Air

Hmm, a 2013 MacBook Air is 4 processor generations newer than Nehalem, so surely it should have all the SIMD features that Nehalem did.

The problem went away when I re-installed everything using the +debug variant, and I'm not sure why.

Well it could be like I said, that rebuilding from source (regardless what variants you choose) fixes the problem by ensuring that only the SIMD capabilities of your processor are used.

[ryandesign (Ryan Carsten Schmidt)]

Though ​johnww2 said here that he didn't think simply rebuilding was the solution.

[johnww2-nwxg]

Hi, this is same johnww2, different git login.

Config (still in use) on which I reported this issue:

  Model Identifier:	MacBookPro11,5
  Processor Name:	Intel Core i7
  Processor Speed:	2.8 GHz

System has been upgraded since problem encountered, now running on:

  System Version:	macOS 10.14.6 (18G103)
  Kernel Version:	Darwin 18.7.0

Xcode:

Version 11.1 (11A1027)

I did do a php73-imap install to pick up recent fix (#58973)

I double checked to see if my Laravel test install started crashing again after this and it still seems to work with minimal testing, but I can't say for sure if my patched version of php is still running at the moment (after doing port install php73-imap)

[slaakso (Seppo Laaksonen)]

Did rebuild from sources (sudo port -ns upgrade --force php73 php73-openssl), still have the problem with openssl_encrypt when accessing through Apache, works ok from command line.

• Xcode command line tools: 11.1 (11A1027)
• macOS 10.14.6 (18G103)
• MacBook Pro (15-inch, 2018), 2.9 GHz Intel Core i9

[ryandesign (Ryan Carsten Schmidt)]

Replying to slaakso:

Did rebuild from sources (sudo port -ns upgrade --force php73 php73-openssl), still have the problem with openssl_encrypt when accessing through Apache, works ok from command line.

Does sudo port -ns upgrade --force php73-apache2handler followed by sudo port reload apache2 fix it for access from Apache?

[slaakso (Seppo Laaksonen)]

Restarting the apache with apachectl did the trick (thought the reinstallation would have restarted the service). All good now. Thank you very much.

So it's the PHP binary in MacPorts that is the culprit even though in my case I'm running Intel Core i9?

[ryandesign (Ryan Carsten Schmidt)]

Reinstalling a port will reload a launchd plist provided by that port. But in the case of php73-apache2handler, it's an Apache module. It doesn't itself have a launchd plist. It's the apache2 port that has the launchd plist, but MacPorts doesn't know that those two ports are related, so you have to restart the service separately.

At this point I don't know what the culprit is. All three of you reporting this problem fixed the problem by rebuilding the port from source (some of you by making additional changes, but it's not clear that those changes were needed). Everyone reporting the problem has a newer CPU than our build machine. In addition, I've ​contacted the php developers for help and they've told me that php will double-check the SIMD capabilities at runtime, so even the scenario I originally considered—with an older CPU than our build machine's—wouldn't be a problem.

If your ports tree is up to date, you shouldn't even be able to use our php binaries—MacPorts should have recognized them as broken and rebuilt them already. They were broken by the icu update; I'm working on that; see #59439.

I'm going to try to reproduce this problem on my own Mojave system by downgrading the ports tree to before the icu update, so that our binaries will work.

[ryandesign (Ryan Carsten Schmidt)]

Well, I'm still not seeing the crash. I made sure to get a binary of php73 @7.3.10_0 and php73-openssl @7.3.10_0 and icu @58.2_2. The machine I'm testing on is:

      Model Name: MacBook Pro
      Model Identifier: MacBookPro10,1
      Processor Name: Intel Core i7
      Processor Speed: 2.6 GHz

      System Version: macOS 10.14.6 (18G103)
      Kernel Version: Darwin 18.7.0

I'm testing by running the scripts from comment:3 and ​PHP bug 77284 on the command line with php73, and they don't crash for me.

I should probably mention here that another ticket was filed, #59422, which may be the same issue.

I'm preparing a php update to fix other issues. I was hoping to include a fix for this issue but I'm not yet sure how. Maybe we can use that update as a further test. I'll post more about that once I've committed the update.

[ryandesign (Ryan Carsten Schmidt)]

I've updated the php ports. If you sudo port selfupdate you'll have the update available. Specifically, the php73 ports are now at 7.3.11_0.

To help us isolate the cause of this problem and hopefully fix it, it would be helpful if anyone who was experiencing the issue would update to php73 @7.3.11_0 using the binaries we compiled to see if they still have the problem. I haven't done anything to fix the problem, so I expect you will still experience it.

To ensure you get our binary, use the -b flag when updating, i.e. sudo port -b upgrade outdated. Not all ports have binaries available. If you encounter a non-php73 port that won't upgrade using a binary (or php73-apache2handler if you're using that, since we have no binaries for that either), sudo port upgrade ... that port alone, then go back to sudo port -b upgrade outdated until you successfully upgrade the php73 ports. Then you can upgrade any remaining ports using sudo port upgrade outdated if needed.

If php73 won't upgrade using a binary, make sure you're using the default variants. If you're using different variants, temporarily try using the default variants, for example by reinstalling the port without specifying variants, e.g. sudo port -b install php73.

If you're using php in a web server environment, remember to restart the web server. If you're using php73-fpm, the launchd plist in the port should restart FPM when the port upgrades, but if you're not using that launchd plist, remember to restart your FPM processes.

---

Assuming you encounter the problem with a binary of 7.3.11_0, then please try rebuilding the affected ports from source and keeping the log file. You can rebuild using the -n and --force flags; you can ensure it's from source using the -s flag; you can keep the log using the -k flag. So for example: sudo port -nsk upgrade --force php73 to rebuild php73 from source and keep the log. Please do this for just one port at a time, then retest. If it still happens, try rebuilding another affected port. Which ports are affected? php73 probably, php73-openssl maybe, and if you're using a different SAPI (php73-apache2handler, php73-cgi, php73-fpm), then that SAPI maybe. Retest after each rebuild, remembering to restart the web server or FPM if applicable.

My hope is that after rebuilding one of these ports, it will work again. Assuming that happens, please attach your log files from your builds to this ticket. The log file's location is printed by running e.g. port logfile php73. We can then compare your logs with those from our build machine to see if there's a difference.

Our build logs:
​php73
​php73-apache2handler
​php73-cgi
​php73-fpm
​php73-openssl

And of course let us know if I'm guessing wrong—if you don't see the problem anymore even with our 7.3.11 binaries, or if you're not able to fix the problem by rebuilding from source. (In the latter case, you can go back to the previous version.)

[TheDigitalOrchard (The Digital Orchard)]

Is there anything special about the non-binary update to 7.3.11? I've updated (not using -b) and now getting random out-of-memory errors that never happened before. First time was at the point of sending output to the browser, but every other crash occurs during OpenSSL decryption. And, randomly, things work just fine.

Here's an example error.

Fatal error: Allowed memory size of 134217728 bytes exhausted at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_php/php73-fpm/work/php-7.3.11/Zend/zend_string.h:133 (tried to allocate 49576 bytes) in /Library/WebServer/lib/xAppOS/CI_libraries/xAppCI_OpenSSL.php on line 48

I haven't dug into it deeper than this yet.

[TheDigitalOrchard (The Digital Orchard)]

The issue could just be specific to my application, as now I'm seeing the same out-of-memory errors occurring at different points of execution, and only when loading a lot of records from the database at once. Memory consumption jumps. I'm not sure if 7.3.11 has different memory thresholds because this crashing never occurred until I updated.

I'll keep monitoring.

[ryandesign (Ryan Carsten Schmidt)]

The "Allowed memory size ... exhausted" message is one of the symptoms of ​the PHP bug we've been talking about above, which affects openssl and base64 functions.

Did your non--b upgrade of php73 to 7.3.11 occur using a binary from our server (did you see messages that a tbz2 archive and its rmd160 signature was downloaded from packages.macports.org or one of its mirrors) or compiled from source on your system (did you see a php-7.3.11.tar.xz source file being downloaded, extracted, configured, built, destrooted)?

The reason why I was asking you to try the binary, and then if it fails to try rebuilding from source and attach the log, is that I am operating under the suspicion that something about the way we are building our binary is not compatible with some users' systems. Our build server uses the same MacPorts with the same portfiles to build the binaries, but there are of course differences: we deactivate all other ports while building, which you don't on your system, so a build from source on your system could pick up undeclared dependencies which our build system wouldn't. And our build system runs as a virtual machine; that could affect how the php build system detects certain characteristics of the system. Comparing your from-source build log with ours could help shed light on whether that is so.

The PHP developers have removed the configure-time checks for the SIMD functions in PHP 7.4, since there are already runtime checks for them. If the problem we're chasing here has to do with possibly incorrect detection of something at configure time, then that might fix the problem. I have started working on adding php74 to MacPorts so that we can see if it is affected too, but several changes were made in the build system that make this a little more difficult than previous port updates, so I don't have an ETA.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

Did your non--b upgrade of php73 to 7.3.11 occur using a binary from our server (did you see messages that a tbz2 archive and its rmd160 signature was downloaded from packages.macports.org or one of its mirrors) or compiled from source on your system (did you see a php-7.3.11.tar.xz source file being downloaded, extracted, configured, built, destrooted)?

A more certain way to answer the question: Run:

grep PHP_UNAME /opt/local/include/php73/php/main/php_config.h

If that prints a hostname ending with .internal.macports.net, it came from our build server; if it shows your computer's hostname, then it was built from source on your computer.

[TheDigitalOrchard (The Digital Orchard)]

It prints my local hostname.

#define PHP_UNAME "Darwin Teds-MacBook-Air.local 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64"

I'm running the +debug variant, but nothing special beyond that.

Still getting random out-of-memory crashing today. Continuing to investigate and establish a pattern.

Heres the latest Fatal error:

Fatal error: Allowed memory size of 134217728 bytes exhausted at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_php/php73-fpm/work/php-7.3.11/main/output.c:899 (tried to allocate 880672 bytes) in /Library/WebServer/lib/xAppOS/CI_libraries/xAppCI_Output.php on line 173

I'm unclear on *why* this started happening. It only happens on pages that involve decrypting a lot of records using OpenSSL.

I'll update when I know more.

[ryandesign (Ryan Carsten Schmidt)]

Replying to TheDigitalOrchard:

It prints my local hostname.

#define PHP_UNAME "Darwin Teds-MacBook-Air.local 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64"

I'm running the +debug variant, but nothing special beyond that.

Ok, so you didn't get our binary. You wouldn't get a binary when using non-default variants.

Still getting random out-of-memory crashing today. Continuing to investigate and establish a pattern.

Heres the latest Fatal error:

Fatal error: Allowed memory size of 134217728 bytes exhausted at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_php/php73-fpm/work/php-7.3.11/main/output.c:899 (tried to allocate 880672 bytes) in /Library/WebServer/lib/xAppOS/CI_libraries/xAppCI_Output.php on line 173

I'm unclear on *why* this started happening. It only happens on pages that involve decrypting a lot of records using OpenSSL.

That disproves my hunch that it had to do with our binaries.

I can try to backport ​the change from php74 to php73 that removes the SIMD configure checks, and you can see if that changes things.

As a last resort I can disable the SIMD functions altogether, as the reporter originally suggested at the top of this ticket. However, that would remove an optimization the PHP developers put in, so if we can avoid that, that would be good.

[TheDigitalOrchard (The Digital Orchard)]

Would a crash log / stack trace help? Remind me where these logs are stored. I've looked in several places, but can't find a recent crash log for PHP-FPM.

Also, this crashing / memory consumption issue... I'm assuming this would only involve the MacPorts version of PHP, which strikes me as odd. I run nearly identical installation on many Ubuntu servers, installed via apt. It would be disastrous if this problem affected 7.3.11 on this other platform. So far I'm not seeing this crash anywhere else, only on my local dev Mac. So it's a mystery.

I'll keep digging.

[slaakso (Seppo Laaksonen)]

Had the crash earlier with 7.3.7. Updated to 7.3.10 compiled from the source and the problem went away (with other compilations).

Now updated to 7.3.11 binary version and everything is still ok. So, good news that it looks like the binary works, but the reason for the original crash is still up in the air.

[ryandesign (Ryan Carsten Schmidt)]

Replying to TheDigitalOrchard:

Would a crash log / stack trace help? Remind me where these logs are stored. I've looked in several places, but can't find a recent crash log for PHP-FPM.

Crash logs are in Library/Logs/DiagnosticReports. Which Library depends on which user the program ran under. If you start a web server as root, for example, it might be /var/root/Library, while if you run under your own user, it would be ~/Library. It wouldn't hurt to attach them, though I'm pretty sure it'll tell us what we already know.

Also, this crashing / memory consumption issue... I'm assuming this would only involve the MacPorts version of PHP, which strikes me as odd.

No, it shouldn't be anything MacPorts-specific, though it may turn out to be macOS-version-specific.

I run nearly identical installation on many Ubuntu servers, installed via apt. It would be disastrous if this problem affected 7.3.11 on this other platform. So far I'm not seeing this crash anywhere else, only on my local dev Mac. So it's a mystery.

Ubuntu is Linux, and I haven't heard of this problem affecting Linux. As mentioned at the top of this ticket, the problem was reported against FreeBSD. They determined that ifuncs are buggy on FreeBSD 11, so they disabled their use on FreeBSD. As I said, and as the original reporter suggested at the top of this ticket, as a last resort, we can do the same on macOS, at the expense of missing out on the optimizations that using the SIMD functions were supposed to provide. macOS is after all based on BSD, not Linux. But you previously reported that just reinstalling with the +debug variant (and not disabling SIMD functions) had solved the problem for you at the time, so I had not been convinced that disabling the SIMD functions was the right thing to do.

[TheDigitalOrchard (The Digital Orchard)]

@Ryan,

I'm withdrawing my suspicion that my out-of-memory issues are related to anything that you've done with the php libraries. I just did a side-by-side comparison of MacPorts PHP 7.3.11 and Ubuntu PHP 7.3.11... same application, same code, but a different number of database records being decrypted. I'm seeing a similar memory consumption on both systems. So it seems that I may have just hit a threshold on my local dev system.... more records than the production system has, and that threshold is causing the out-of-memory errors.

Sorry for the noise.

[ryandesign (Ryan Carsten Schmidt)]

Please check if you still see the problem with php74.

[slaakso (Seppo Laaksonen)]

Replying to ryandesign:

Please check if you still see the problem with php74.

openssl_encrypt seems to be working without problems. Still hoping for php74-zip.

[ryandesign (Ryan Carsten Schmidt)]

Replying to slaakso:

Replying to ryandesign:

Please check if you still see the problem with php74.

openssl_encrypt seems to be working without problems.

Ok good. That gives me hope that backporting a fix or two to php73 will solve the problem there too.

Still hoping for php74-zip.

See [27914c4b282636988711360abdfe1f907f2fbb33/macports-ports].

[miken32 (Michael Newton)]

Seeing the same behaviour here, running a Laravel app. Disabling the OpenSSL module gave me an exception when it tried using openssl_* functions, but otherwise it just crashed Apache with the bus error messages noted above. A test page with just a call to php_info() worked fine.

I rebuilt the php73 port from source with no effect.

Rebuilding the php73-openssl port from source resolved the issue for me.

Early 2015 MacBook Pro 12,1 running Catalina

[carbonturtle (Michael Hosford)]

I encountered this issue this week when setting up a Laravel 7 (7.26.0) web app for the first time. I only experienced the problem in a web server environment; I did not try to re-create it via command-line PHP execution.

System Info

• MacOS Mojave 10.14.6 (18G6020)
• 2018 MacBookPro15,1
• 2.9 GHz Intel Core i9
• Xcode 11.3.1 (15715) with macOS 10.14 (18G74) and 10.15 (19B90) SDKs
• MacPorts php73 (7.3.16_0)
• MacPorts php73-apache2handler (7.3.16_0)

From the crash log:

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

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   ???                           	0x00000001081b15c0 php_base64_encode + 0
1   openssl.so                    	0x000000010ae9d8c9 zif_openssl_encrypt + 505
2   mod_php73.so                  	0x0000000107ac08f6 ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER + 80
3   mod_php73.so                  	0x0000000107a78d50 execute_ex + 98
4   mod_php73.so                  	0x0000000107a78ecc zend_execute + 318
5   mod_php73.so                  	0x0000000107a3d5f2 zend_execute_scripts + 277
6   mod_php73.so                  	0x00000001079e88a9 php_execute_script + 655
7   mod_php73.so                  	0x0000000107ae7ac8 php_handler + 1045
8   httpd                         	0x00000001073ed087 ap_run_handler + 51
9   httpd                         	0x00000001073ed641 ap_invoke_handler + 240

First I tried updating to 7.3.16_1 via sudo port upgrade outdated and reloading Apache, but this didn't fix it.

Then I rebuilt php73-openssl with sudo port -ns upgrade --force php73-openssl and reloaded Apache, still no luck.

Lastly, I tried sudo port -ns upgrade --force php73 php73-openssl and reloaded Apache and that did the trick.

I don't know whether there were any MacPorts binaries involved before I forced the rebuild. Is it MacPorts' default behavior to provide binaries when available? I had assumed it was building everything from source.

Note: A month ago, I encountered a problem (documented in ticket #59837 "macOS 10.14 SDK does not appear to be installed even though Command Line Tools are installed") which I resolved by symlinking the 10.14 SDK as suggested in ticket:59837#comment:27. Mentioning it in case it's possible that the last time I upgraded php73* the build was somehow broken due to that issue. That said, I use my local web server on an almost-daily basis and never encountered any problems with php73 before now.

Many thanks to Ryan and the others for blazing this trail and saving me lots of time and frustration.

[ryandesign (Ryan Carsten Schmidt)]

Ooh. I forgot this was still an issue.

Replying to carbonturtle:

Is it MacPorts' default behavior to provide binaries when available?

Yes. If you see lines showing successful fetches from packages.macports.org or one of its mirrors followed immediately by installation and activation, you got a binary.

I had assumed it was building everything from source.

If you see lines showing failed fetches from packages.macports.org or one of its mirrors (or no lines showing attempted fetches from those servers) and then lines saying it's fetching, extracting, patching, configuring, building, and staging into destroot, that's a build from source.

[hostep (Pieter Hoste)]

Ran into this problem as well today. Triggered it in a Magento 2 shop by running bin/magento setup:di:compile which crashed with "Bus error: 10"
This is the first time I ran into this problem on this project, last week I upgraded php73 from @7.3.33_0+libedit to @7.3.33_1+libedit, maybe that triggered it somehow? (which would be weird)

And I can also reproduce this with the code from #comment:3

Using:

• macOS Big Sur 11.6.3
• Xcode command line tools 13.2.0
• MacBook Pro (15-inch, 2017)
• 2,9 GHz Quad-Core Intel Core i7
• Using php73 @7.3.33_1+libedit

Executing sudo port -ns upgrade --force php73-openssl fixed it over here (first tried sudo port -ns upgrade --force php73 but that didn't help)

Thanks for all the info in this ticket here, it really helped!