port command killed by OS after selfupdate to 2.11.1

[McDutchie (Martijn Dekker)]

Running macOS Sequoia 15.5 arm64.

The upgrade to the latest version failed as follows:

$ sudo port selfupdate && port outdated
--->  Checking for newer releases of MacPorts
MacPorts base version 2.11.0 installed,
MacPorts base version 2.11.1 available.
--->  MacPorts base is outdated, installing new version 2.11.1
--->  Attempting to fetch MacPorts 2.11.1 source code from https://github.com/macports/macports-base/releases/download/v2.11.1/MacPorts-2.11.1.tar.bz2
--->  Extracting MacPorts 2.11.1                                                     
--->  Installing new MacPorts release in /opt/local as root:wheel; permissions 0755
Error: Error installing new MacPorts base: command execution failed
Please run `port -v selfupdate' for details.
Error: /opt/local/bin/port: port selfupdate failed: Error installing new MacPorts base: command execution failed

But I cannot provide the requested details because the port command has become unusable:

$ sudo port -v selfupdate
Killed
$ port outdated
Killed
$ port
Killed

MacPorts is killing itself with SIGKILL for some reason.

[tux-o-matic (Benjamin Merot)]

Same here. Console logs point toward macOS protection (code signing, etc...) killing the tcl process launched by the port CLI.

[jmroot (Joshua Root)]

Needless to say, I didn't see this in testing. The changes from 2.11.0 to 2.11.1 are not large and I don't see how they could cause something like this. ​https://github.com/macports/macports-base/compare/v2.11.0...v2.11.1

If someone can run sudo port -d selfupdate on a 2.11.0 machine and see what's happening at the point where it's killed, that would be very helpful.

In the meantime, if code signing is the issue, hopefully using the .pkg installer might be a workaround since it's notarized.

[jmroot (Joshua Root)]

If someone seeing this could also check if ./configure && make && make install works with the 2.11.1 source, that would also be useful data.

[tux-o-matic (Benjamin Merot)]

Without re-installing, maybe this can help you get on the right track:

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               tclsh8.6 [62557]
Path:                  /opt/local/libexec/*/tclsh8.6
Identifier:            tclsh8.6
Version:               8.6.16 (8.6.16)
Code Type:             ARM-64 (Native)
Parent Process:        Exited process [59755]
Responsible:           Terminal [24349]
User ID:               0

System Integrity Protection: enabled

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

Exception Type:        EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))

[neverpanic (Clemens Lang)]

Replying to tux-o-matic:

Without re-installing, maybe this can help you get on the right track:

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               tclsh8.6 [62557]
Path:                  /opt/local/libexec/*/tclsh8.6
Identifier:            tclsh8.6
Version:               8.6.16 (8.6.16)
Code Type:             ARM-64 (Native)
Parent Process:        Exited process [59755]
Responsible:           Terminal [24349]
User ID:               0

System Integrity Protection: enabled

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

Exception Type:        EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))

Sounds like the code signature for tclsh8.6 is invalid, which is weird because selfupdate should be building that on your own machine.

I'll take a look at the code signature of this binary in the .pkg installer just for good measure, although I'm not sure it's related.

[neverpanic (Clemens Lang)]

Can anybody affected please run

codesign --verbose --display --verbose --all-architectures --check-notarization /opt/local/libexec/macports/bin/tclsh8.6

and report its output.

The binary in the .pkg is good:

Executable=/Users/cllang/Downloads/tclsh8.6
Identifier=org.macports.base
Format=Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=477 flags=0x10000(runtime) hashes=9+2 location=embedded
Signature size=8973
Authority=Developer ID Application: Joshua Root (QTA3A3B7F3)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=14. Jul 2025 at 09:44:41
Info.plist entries=10
TeamIdentifier=QTA3A3B7F3
Runtime Version=15.5.0
Sealed Resources=none
Internal requirements count=1 size=180

so re-running the installer pkg should work around the issue.

[tux-o-matic (Benjamin Merot)]

% codesign --verbose --display --verbose --all-architectures --check-notarization /opt/local/libexec/macports/bin/tclsh8.6
Executable=/opt/local/libexec/macports/bin/tclsh8.6
Identifier=tclsh
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=382 flags=0x20002(adhoc,linker-signed) hashes=9+0 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none

That's it.

[jmroot (Joshua Root)]

Replying to jmroot:

If someone can run sudo port -d selfupdate on a 2.11.0 machine and see what's happening at the point where it's killed, that would be very helpful.

Well the good news is we have this output, the bad news is that's because it also happened on the buildbot. ​https://build.macports.org/builders/ports-14_arm64-watcher/builds/22120/steps/selfupdate/logs/stdio

Looks like it's exactly the error reported above near the very end of make install, when it runs some scripts that use the files that were just installed.

[jmroot (Joshua Root)]

Duplicate #72690 confirms that installing from source outside of selfupdate works.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jmroot:

Well the good news is we have this output, the bad news is that's because it also happened on the buildbot. ​https://build.macports.org/builders/ports-14_arm64-watcher/builds/22120/steps/selfupdate/logs/stdio

In the case of that buildbot worker, 2.11.1 did get installed despite the error:

% /opt/local/bin/port vers
Version: 2.11.1

[jmroot (Joshua Root)]

Replying to ryandesign:

In the case of that buildbot worker, 2.11.1 did get installed despite the error:

Right, it only failed when it got to the post-installation scripts (which fortunately are probably OK to skip for this update). Interesting that unlike for the ticket reporter, port is working afterwards.

[cjones051073 (Chris Jones)]

port also 'worked' for me after I had a failure to self update from 2.11.0 to 2.11.1. I guess depending on what is skipped and where you are updating from it could just be luck if what you end up with works or not.

Also, I suspect I had a similar issue on the original self update *to* 2.11.0, but as I was in a hurry at the time and port was seemingly working I didn't look into it at the time. Its only when it happened again with 2.11.1 I took the time to investigate. So don't fixate on the diffs from 2.11.0 to 2.11.1 as I think the problem is from before then.

[jmroot (Joshua Root)]

Searching turned up this: ​https://discourse.llvm.org/t/ad-hoc-code-signature-anomaly-on-arm64-macos/57628

which feels a bit like this obligatory XKCD: ​https://xkcd.com/979/

[ryandesign (Ryan Carsten Schmidt)]

Replying to jmroot:

Searching turned up this: ​https://discourse.llvm.org/t/ad-hoc-code-signature-anomaly-on-arm64-macos/57628

A problem that was fixed after copying the program or just waiting? Sounds like the filesystem bug #67336 again.

[McDutchie (Martijn Dekker)]

This issue just got more bizarre on my end. After filing it, I had to do other stuff for some hours, only coming back to it now. I've not been touching anything MacPorts-related at all. Yet, my port command is now working normally, and I seem to have a functional MacPorts 2.11.1 installation, though I've changed absolutely nothing!

[kwolcott]

Just waiting seems to be the 'ticket' (no pun intended) for me.

[ryandesign (Ryan Carsten Schmidt)]

We worked around the filesystem bug in #67336 when installing a port, but we might need to do the same thing in the selfupdate code.

Anyone currently experiencing the problem can try running sudo /usr/sbin/purge to purge the disk cache. If port then starts working, that would support the filesystem bug theory.

[dojoteef (Nader Akoury)]

Ran into this issue and waited several hours to no avail. Just ran sudo /usr/sbin/purge and port immediately started working.

[akierig (akierig)]

so FWIW, it failed on my two MBPs on MacOS 15.5. I ran it on my third machine also on 15.5, running sudo /usr/sbin/purge before hand. upgrading MacPorts failed like everyone else, though running purge then port selfupdate ran fine.

Just to provide another bit of data.

[klausness]

Interesting. Mine failed, too. I tried running purge, as ryandesign, dojoteef, and akierig suggested, and then ran selfupdate again. Selfupdate told me that 2.11.1 was already installed successfully, and I was able to proceed to use port normally. So (fingers crossed) running purge after the failed selfupdate seems to fix things. So it may well be that filesystem bug that ryandesign mentioned.

[nihilismus (Antonio Hernández Blas)]

Same here, sudo /usr/sbin/purge and sudo port selfupdate fixed the issue.

[JDLH (Jim DeLaHunt)]

I just encountered this problem. Similar to comment:22 and comment:23, sudo /usr/sbin/purge and sudo port selfupdate fixed the issue. I am on macOS Sonoma 14.7.6 (23H626), and an M1 CPU.

The first place I looked for help on this matter was the FAQ. The second place was the Problem Hotlist. Might I suggest that this issue be added to one of those two places?

[jmroot (Joshua Root)]

Well that's horrible. Everyone affected, please send feedback to Apple so they might investigate and properly fix the underlying bug.

[EvilJordan (Jordan Holberg)]

This affected me, too, and I know the last thing anyone wants is a "me too!" post with no helpful info. HOWEVER, I wanted to take the opportunity on this ticket to say how easy it was to find, read, and see dev engagement, and find a fix. THANK YOU to everyone in the community!

[ryandesign (Ryan Carsten Schmidt)]

For anyone who has not yet run sudo /usr/sbin/purge and is still seeing the problem where port is killed by the OS, can you please try just running cp -c /opt/local/libexec/macports/bin/tclsh8.6 /tmp and then try the port command again? Let us know if that is sufficient. That's the less-invasive workaround Josh found for the filesystem bug in #67336; just cloning the affected program seems to repair the original.

The filesystem bug has been around since Catalina and only happened very occasionally. Josh, any idea why the problem is now surfacing so frequently in selfupdate? Did something change about how selfupdate works in the 2.11 branch?

[ryandesign (Ryan Carsten Schmidt)]

Replying to JDLH:

The first place I looked for help on this matter was the FAQ. The second place was the Problem Hotlist. Might I suggest that this issue be added to one of those two places?

Added: ProblemHotlist#selfupdate

[ryandesign (Ryan Carsten Schmidt)]

To collect some info on which systems are affected, could everyone who had this problem please show the output of:

sw_vers; xcodebuild -version; pkgutil --pkg-info=com.apple.pkg.CLTools_Executables; /usr/bin/clang --version

Put {{{ on a line by itself before the output and }}} on a line by itself after the output to format it correctly.

Also let us know what version of MacPorts you were upgrading from and to. I'd like to know if this is only seen when upgrading from MacPorts 2.11.x or also when upgrading from earlier versions.

[tux-o-matic (Benjamin Merot)]

Sure thing.

Happened when upgrading from 2.11.0.

ProductName:		macOS
ProductVersion:		15.5
BuildVersion:		24F74
Xcode 16.4
Build version 16F6
package-id: com.apple.pkg.CLTools_Executables
version: 16.4.0.0.1.1747106510
volume: /
location: /
install-time: 1748793854
Apple clang version 17.0.0 (clang-1700.0.13.5)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[klausness]

ProductName:		macOS
ProductVersion:		15.5
BuildVersion:		24F74
Xcode 16.4
Build version 16F6
package-id: com.apple.pkg.CLTools_Executables
version: 16.4.0.0.1.1747106510
volume: /
location: /
install-time: 1751885379
Apple clang version 17.0.0 (clang-1700.0.13.5)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Upgrading from 2.11.0 to 2.11.1

[Alex11N]

Replying to jmroot:

Well that's horrible. Everyone affected, please send feedback to Apple so they might investigate and properly fix the underlying bug.

I've been filing crash reports to Apple regularly for the last two or three months (after macOS 15.4 was released) after I get a kernel panic and machine reboot every Monday afternoon after 2 pm. Given that there has been no resolution to this, I'm not convinced that sending and feedback to Apple is going to help in any way whatsoever.

I've had the same problem as everyone else with the MacPorts 2.11.1 update, and it had resolved itself by the time that I got back to the computer this evening, 24 hours later.

[menzelcom (Christian Menzel)]

This did work on my end:

cp -c /opt/local/libexec/macports/bin/tclsh8.6 /tmp

Thanks @ryandesign

[dojoteef (Nader Akoury)]

ProductName:            macOS
ProductVersion:         15.5
BuildVersion:           24F74
Xcode 16.3
Build version 16E140
package-id: com.apple.pkg.CLTools_Executables
version: 16.4.0.0.1.1747106510
volume: /
location: /
install-time: 1749583951
Apple clang version 17.0.0 (clang-1700.0.13.3)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Upgrading from 2.11.0 to 2.11.1

[wlipa (Bill Lipa)]

ProductName:		macOS
ProductVersion:		15.5
BuildVersion:		24F74
Xcode 16.4
Build version 16F6
package-id: com.apple.pkg.CLTools_Executables
version: 16.4.0.0.1.1747106510
volume: /
location: /
install-time: 1748490147
Apple clang version 17.0.0 (clang-1700.0.13.5)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

From 2.11.0 to 2.11.1. Self-healed after a couple hours without me doing anything.

[jmroot (Joshua Root)]

Replying to Alex11N:

I've been filing crash reports to Apple regularly for the last two or three months (after macOS 15.4 was released) after I get a kernel panic and machine reboot every Monday afternoon after 2 pm. Given that there has been no resolution to this, I'm not convinced that sending and feedback to Apple is going to help in any way whatsoever.

There are clearly more reports than they are able to respond to individually, and they prioritise issues that affect more people. But I have received helpful responses to feedback reports before.

I filed FB18853710 about this, if people want to reference it in theirs. However I have still not been able to reproduce the problem, and Apple could probably really use a sysdiagnose from a system that has experienced the problem, or ideally one that is currently experiencing it.

[jmroot (Joshua Root)]

Replying to ryandesign:

The filesystem bug has been around since Catalina and only happened very occasionally. Josh, any idea why the problem is now surfacing so frequently in selfupdate? Did something change about how selfupdate works in the 2.11 branch?

Literally nothing has changed in selfupdate.tcl since 2.10.3.

[JDLH (Jim DeLaHunt)]

I encountered this problem when upgrading from macports 2.11.0 to 2.11.1. My system's version of the requested diagnostics (unchanged, as far as I know, from when the problem occurred yesterday):

% sw_vers; xcodebuild -version; pkgutil --pkg-info=com.apple.pkg.CLTools_Executables; /usr/bin/clang --version

ProductName:		macOS
ProductVersion:		14.7.6
BuildVersion:		23H626
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
package-id: com.apple.pkg.CLTools_Executables
version: 16.2.0.0.1.1733547573
volume: /
location: /
install-time: 1734383583
Apple clang version 16.0.0 (clang-1600.0.26.6)
Target: arm64-apple-darwin23.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

And since I have XCode Command Line Tools but not XCode itself, the following might be useful:

% pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
package-id: com.apple.pkg.CLTools_Executables
version: 16.2.0.0.1.1733547573
volume: /
location: /
install-time: 1734383583

[hapaguy (Brian Kurt Fujikawa)]

port selfupdate failed upgrading to MacPorts 2.11.1. I recovered after executing

sudo /usr/sbin/purge

Here's the other relevant info:

% sw_vers; xcodebuild -version; pkgutil --pkg-info=com.apple.pkg.CLTools_Executables; /usr/bin/clang --version
ProductName:		macOS
ProductVersion:		15.5
BuildVersion:		24F74
Xcode 16.4
Build version 16F6
package-id: com.apple.pkg.CLTools_Executables
version: 16.4.0.0.1.1747106510
volume: /
location: /
install-time: 1748489182
Apple clang version 17.0.0 (clang-1700.0.13.5)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[jmroot (Joshua Root)]

[23e60c742b5904c6230590ee54db9310034ea518/macports-base] may double as a workaround for this, though since I can't reproduce the issue I also can't evaluate the effectiveness of potential mitigations.

[thomasrussellmurphy (Thomas Russell Murphy)]

I had selfupdate fail, but my port kept working and, in fact, had the 2.11.1 version installed, so no further ability to run selfupdate.

$ sw_vers; xcodebuild -version; pkgutil --pkg-info=com.apple.pkg.CLTools_Executables; /usr/bin/clang --version
ProductName:		macOS
ProductVersion:		15.5
BuildVersion:		24F74
Xcode 16.3
Build version 16E140
No receipt for 'com.apple.pkg.CLTools_Executables' found at '/'.
Apple clang version 17.0.0 (clang-1700.0.13.3)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I have also submitted a Feedback Assistant ticket with my system config about this issue. Might not be an exact match since I wasn't blocked after the first time port failed.

[jmroot (Joshua Root)]

Replying to thomasrussellmurphy:

I had selfupdate fail, but my port kept working and, in fact, had the 2.11.1 version installed, so no further ability to run selfupdate.

It is possible to force a selfupdate when base is not outdated with the -f option, i.e. sudo port -f selfupdate. That actually might be an informative experiment.

[cjones051073 (Chris Jones)]

Replying to jmroot:

Replying to thomasrussellmurphy:

I had selfupdate fail, but my port kept working and, in fact, had the 2.11.1 version installed, so no further ability to run selfupdate.

It is possible to force a selfupdate when base is not outdated with the -f option, i.e. sudo port -f selfupdate. That actually might be an informative experiment.

Forcing a self update ( so from 2.11.1 to 2.11.1) I see the same problem.

Regarding testing [23e60c742b5904c6230590ee54db9310034ea518/macports-base] I would happily try it, but I have no clue how to force a self update to that GitHub version. Is that even possible to do ? I can install from GitHub source, thats easily enough, but we already know that the issue does not happen that route so that proves nothing really.

[cjones051073 (Chris Jones)]

So I just installed [23e60c742b5904c6230590ee54db9310034ea518/macports-base] and then tried a forced self update. That actually was a downgrade from 2.11.99 (i.e. the master version from GitHub) to 2.11.1. That failed in the same way as before.

Of course, thats not really the test we need, we want to see if a self update *to* 2.11.99 fails or not, but I have no clue how to do that.

[McDutchie (Martijn Dekker)]

I can reliably reproduce the problem again with port -f selfupdate. Below is the output of that reproduction as well as my software versions, as requested. Note I only have the command line dev tools installed, not the full Xcode.

$ sudo port -f selfupdate
--->  Checking for newer releases of MacPorts
MacPorts base version 2.11.1 installed,
MacPorts base version 2.11.1 available.
--->  MacPorts base is outdated, installing new version 2.11.1
Verified existing file for https://github.com/macports/macports-base/releases/download/v2.11.1/MacPorts-2.11.1.tar.bz2
--->  Extracting MacPorts 2.11.1
--->  Installing new MacPorts release in /opt/local as root:wheel; permissions 0755
Error: Error installing new MacPorts base: command execution failed
Please run `port -v selfupdate' for details.
Error: /opt/local/bin/port: port selfupdate failed: Error installing new MacPorts base: command execution failed
$ port
Killed
$ sudo purge
$ port
MacPorts 2.11.1
Entering shell mode... ("help" for help, "quit" to quit)
[Users/martijn] > quit
Goodbye
$ (set -x; sw_vers; xcodebuild -version; pkgutil --pkg-info=com.apple.pkg.CLTools_Executables; /usr/bin/clang --version)
+ sw_vers
ProductName:		macOS
ProductVersion:		15.5
BuildVersion:		24F74
+ xcodebuild -version
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
+ pkgutil '--pkg-info=com.apple.pkg.CLTools_Executables'
package-id: com.apple.pkg.CLTools_Executables
version: 16.4.0.0.1.1747106510
volume: /
location: /
install-time: 1749089222
+ /usr/bin/clang --version
Apple clang version 17.0.0 (clang-1700.0.13.5)
Target: arm64-apple-darwin24.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

[jmroot (Joshua Root)]

Replying to cjones051073:

Forcing a self update ( so from 2.11.1 to 2.11.1) I see the same problem.

If you haven't already, please run sysdiagnose while the issue is occurring and send the result to Apple. Feedback Assistant will do this for you automatically when you send a report.

Regarding testing [23e60c742b5904c6230590ee54db9310034ea518/macports-base] I would happily try it, but I have no clue how to force a self update to that GitHub version. Is that even possible to do ?

It's not exactly simple but it is possible.

1. Generate a signify key pair. You will be prompted for a passphrase to secure the secret key; keep that somewhere safe.

   $ /opt/local/libexec/macports/bin/signify -G -c "Local test key for MacPorts selfupdate" -p mp-local.pub -s mp-local.sec
   

2. Put the public key where MacPorts will use it.

   $ sudo mv mp-local.pub /opt/local/share/macports/keys/base
   

3. Edit macports.conf and set release_urls to somewhere that you can make files available.

   release_urls file:///tmp/selfupdate/MacPorts-{version}.tar.bz2
   

4. Create your patched source tree and tarball.

   $ tar -xjf MacPorts-2.11.1.tar.bz2
   $ patch -d MacPorts-2.11.1 -p1 < 23e60c7.diff
   $ touch MacPorts-2.11.1/configure
   $ tar -cjf MacPorts-2.11.1.tar.bz2 MacPorts-2.11.1
   

5. Sign the tarball and put it in place.

   $ /opt/local/libexec/macports/bin/signify -S -s mp-local.sec -m MacPorts-2.11.1.tar.bz2
   $ mv MacPorts-2.11.1.tar.bz2 MacPorts-2.11.1.tar.bz2.sig /tmp/selfupdate/
   

6. Selfupdate. sudo port -vf selfupdate

[ryandesign (Ryan Carsten Schmidt)]

Replying to jmroot:

the bad news is that's because it also happened on the buildbot.

On that machine:

ProductName:		macOS
ProductVersion:		14.7.1
BuildVersion:		23H222
Xcode 15.4
Build version 15F31d
package-id: com.apple.pkg.CLTools_Executables
version: 15.3.0.0.1.1708646388
volume: /
location: /
install-time: 1731445346
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: arm64-apple-darwin23.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I was able to reproduce the problem on this machine by running sudo port -df selfupdate (although it didn't reproduce every time).

What's weird is that tclsh8.6 itself works, as does having it run upgrade_sources_conf_default.tcl, but having tclsh8.6 run port or images_to_archives.tcl doesn't work.

/opt/local/libexec/macports/bin/tclsh8.6 ./src/upgrade_sources_conf_default.tcl "/opt/local"
/opt/local/libexec/macports/bin/tclsh8.6 ./src/images_to_archives.tcl
make: *** [install] Killed: 9

This manifestation of the filesystem bug seems different. Instead of the filesystem cache misidentifying sparse holes, it's misidentifying code signing information.

The crash log always mentions:

Exception Type:        EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))

Termination Reason:    Namespace CODESIGNING, Code 2 Invalid Page

It seems to be crashing when trying to dlopen a library:

VM Region Info: 0x102e5c000 is in 0x102e5c000-0x102ec8000;  bytes after start: 0  bytes before end: 442367
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      __LINKEDIT                  102e54000-102e5c000    [   32K] r--/rwx SM=COW  /opt/local/libexec/*/registry.dylib
--->  mapped file                 102e5c000-102ec8000    [  432K] r--/rwx SM=COW  Object_id=73884a4
      GAP OF 0xc0000 BYTES
      __TEXT                      102f88000-103088000    [ 1024K] r-x/rwx SM=COW  /opt/local/libexec/*/libsqlite3.47.2.dylib

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   dyld                          	       0x1839e518c dyld3::MachOFile::compatibleSlice(Diagnostics&, void const*, unsigned long, char const*, dyld3::Platform, bool, dyld3::GradedArchs const&, bool) + 84
1   dyld                          	       0x1839b5b6c invocation function for block in dyld4::JustInTimeLoader::makeJustInTimeLoaderDisk(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, bool, unsigned int, mach_o::Layout const*) + 96
2   dyld                          	       0x1839ba1a4 dyld4::SyscallDelegate::withReadOnlyMappedFile(Diagnostics&, char const*, bool, void (void const*, unsigned long, bool, dyld4::FileID const&, char const*) block_pointer) const + 132
3   dyld                          	       0x1839b5ad8 dyld4::JustInTimeLoader::makeJustInTimeLoaderDisk(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, bool, unsigned int, mach_o::Layout const*) + 208
4   dyld                          	       0x1839aa878 dyld4::Loader::makeDiskLoader(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, bool, unsigned int, mach_o::Layout const*) + 172
5   dyld                          	       0x1839abfc4 invocation function for block in dyld4::Loader::getLoader(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&) + 2332
6   dyld                          	       0x1839aaf24 dyld4::Loader::forEachResolvedAtPathVar(dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, dyld4::ProcessConfig::PathOverrides::Type, bool&, void (char const*, dyld4::ProcessConfig::PathOverrides::Type, bool&) block_pointer) + 776
7   dyld                          	       0x183999fac dyld4::ProcessConfig::PathOverrides::forEachPathVariant(char const*, dyld3::Platform, bool, bool, bool&, void (char const*, dyld4::ProcessConfig::PathOverrides::Type, bool&) block_pointer) const + 1232
8   dyld                          	       0x1839aaa5c dyld4::Loader::forEachPath(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&, void (char const*, dyld4::ProcessConfig::PathOverrides::Type, bool&) block_pointer) + 248
9   dyld                          	       0x1839ab150 dyld4::Loader::getLoader(Diagnostics&, dyld4::RuntimeState&, char const*, dyld4::Loader::LoadOptions const&) + 492
10  dyld                          	       0x1839d251c dyld4::APIs::dlopen_from(char const*, int, void*)::$_1::operator()() const + 244
11  dyld                          	       0x1839caa68 dyld4::APIs::dlopen_from(char const*, int, void*) + 1164
12  libtcl8.6.dylib               	       0x10345ae60 TclpDlopen + 152
13  libtcl8.6.dylib               	       0x1033ff4e8 Tcl_LoadFile + 108
14  libtcl8.6.dylib               	       0x103404700 Tcl_LoadObjCmd + 1512
15  libtcl8.6.dylib               	       0x103354130 Tcl_EvalObjv + 340
16  libtcl8.6.dylib               	       0x103355380 TclEvalEx + 2368
17  libtcl8.6.dylib               	       0x1033fe840 Tcl_FSEvalFileEx + 748
18  libtcl8.6.dylib               	       0x103405a60 Tcl_MainEx + 1052
19  tclsh8.6                      	       0x102d6ba4c main + 48
20  dyld                          	       0x183997154 start + 2476

cp -c /opt/local/libexec/macports/bin/tclsh8.6 /tmp didn't fix it for me but sudo /usr/sbin/purge did, as did just waiting some minutes.

Replying to jmroot:

Literally nothing has changed in selfupdate.tcl since 2.10.3.

I wonder if it's any significance that tclsh was updated to 8.6.16 in MacPorts 2.11.0.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jmroot:

It's not exactly simple but it is possible.

1. Generate a signify key pair. You will be prompted for a passphrase to secure the secret key; keep that somewhere safe.

   $ /opt/local/libexec/macports/bin/signify -G -c "Local test key for MacPorts selfupdate" -p mp-local.pub -s mp-local.sec
   

2. Put the public key where MacPorts will use it.

   $ sudo mv mp-local.pub /opt/local/share/macports/keys/base
   

3. Edit macports.conf and set release_urls to somewhere that you can make files available.

   release_urls file:///tmp/selfupdate/MacPorts-{version}.tar.bz2
   

4. Create your patched source tree and tarball.

   $ tar -xjf MacPorts-2.11.1.tar.bz2
   $ patch -d MacPorts-2.11.1 -p1 < 23e60c7.diff
   $ touch MacPorts-2.11.1/configure
   $ tar -cjf MacPorts-2.11.1.tar.bz2 MacPorts-2.11.1
   

5. Sign the tarball and put it in place.

   $ /opt/local/libexec/macports/bin/signify -S -s mp-local.sec -m MacPorts-2.11.1.tar.bz2
   $ mv MacPorts-2.11.1.tar.bz2 MacPorts-2.11.1.tar.bz2.sig /tmp/selfupdate/
   

6. Selfupdate. sudo port -vf selfupdate

I did these steps and forced selfupdate five times and it did not fail. So your fix may have been effective. (Thanks!)

[jmroot (Joshua Root)]

Replying to ryandesign:

What's weird is that tclsh8.6 itself works, as does having it run upgrade_sources_conf_default.tcl, but having tclsh8.6 run port or images_to_archives.tcl doesn't work.

The former doesn't use the macports API or otherwise load any libraries.

This manifestation of the filesystem bug seems different. Instead of the filesystem cache misidentifying sparse holes, it's misidentifying code signing information.

Maybe. I don't know whether the Mach-O loader or the code signature verification code use SEEK_DATA.

It seems to be crashing when trying to dlopen a library: cp -c /opt/local/libexec/macports/bin/tclsh8.6 /tmp didn't fix it for me but sudo /usr/sbin/purge did, as did just waiting some minutes.

Looks like it's loading libsqlite3.47.2.dylib, so that would be the file that needs to be fixed by cloning.

I wonder if it's any significance that tclsh was updated to 8.6.16 in MacPorts 2.11.0.

Could be. The bundled sqlite version is certainly different. But we're dealing with closed source code that is likely failing to initialise some values correctly, so it's hard to know exactly what will tickle it the wrong way.

I did these steps and forced selfupdate five times and it did not fail. So your fix may have been effective. (Thanks!)

Great, thanks for testing! I guess we can ship it and see, since it shouldn't do any harm.

[jmroot (Joshua Root)]

Calling this fixed on our end, though the OS bug remains and should continue to be reported to Apple by as many people as possible.