Segmentation Fault during rev-upgrade

[MeNdMont (MeNdMont)]

port rev upgrade

returns the following

--->  Scanning binaries for linking errors
      [                                        ]  85.6 %Segmentation fault: 11

When run with the -d flag

DEBUG: Copying /Users/jon/Library/Preferences/com.apple.dt.Xcode.plist to /opt/local/var/macports/home/Library/Preferences
--->  Scanning binaries for linking errors
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/Library/Frameworks/BGHUDAppKit.framework/Versions/A/Resources/BGHUDAppKitPlugin.ibplugin/Contents/MacOS/BGHUDAppKitPlugin
DEBUG: Missing architecture i386 in file /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
DEBUG: Missing architecture i386 in file outside prefix referenced from /opt/local/share/cmake-3.18/Modules/Internal/CPack/CPack.OSXScriptLauncher.in
DEBUG: skipping ppc in /opt/local/share/cmake-3.18/Modules/Internal/CPack/CPack.OSXScriptLauncher.in since this system can't run it anyway
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-8.0/bin/bugpoint

The

DEBUG: Ignoring loadcommand

continues through many files in /opt/local/libexec/llvm-8.0/bin/

Full output of port -d rev-upgrade attacehed in text file.

[MeNdMont (MeNdMont)]

stderr output

[kpreid (Kevin Reid)]

I'm also getting segfaults from rev-upgrade. My last line of output is

DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/qt5/bin/qdoc

so that's probably just the last library it didn't crash on. I looked at crash logs (/Library/Logs/DiagnosticReports/tclsh8.5_*) and they consistently show this:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   ???                           	000000000000000000 0 + 0
1   machista.dylib                	0x0000000109da957f macho_parse_file + 127
2   machista.dylib                	0x0000000109dae05d _wrap_parse_file + 157 (machista_wrap.c:2230)
3   libtcl8.5.dylib               	0x000000010606f7fd TclEvalObjvInternal + 1098
4   libtcl8.5.dylib               	0x00000001060abbb6 TclExecuteByteCode + 6542
5   libtcl8.5.dylib               	0x00000001060b261b TclCompEvalObj + 211
...

I'm using MacPorts 2.6.4 on Catalina 10.15.7.

[ryandesign (Ryan Carsten Schmidt)]

"Ignoring loadcommand containing @rpath" is completely normal output for some libraries and is not a cause for concern.

I feel like I've seen a similar report of a crash in rev-upgrade recently in a ticket or mailing list post but I cannot find it now.

The code of macho_parse_file is here: ​https://github.com/macports/macports-base/blob/master/src/machista1.0/libmachista.c#L453

[jmroot (Joshua Root)]

This could potentially happen if you built against the macOS 11.0 SDK but are running on 10.15? There's no weak-linking check around use of _dyld_shared_cache_contains_path.

[MeNdMont (MeNdMont)]

Today it only gets to 80.2% and has a some differences:

      [                                        ]  80.2 %Segmentation fault: 11

--->  Scanning binaries for linking errors
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/Library/Frameworks/BGHUDAppKit.framework/Versions/A/Resources/BGHUDAppKitPlugin.ibplugin/Contents/MacOS/BGHUDAppKitPlugin
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-8.0/bin/bugpoint

[coateconnection (David Coate)]

Same error, Catalina 10.15.7. Started happening as soon as base updated from 2.6.3 to 2.6.4 and happens every time port upgrade is run, regardless of whether any ports need upgrading or not.

[MeNdMont (MeNdMont)]

The error appears to have gone away.

--->  Scanning binaries for linking errors
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/Library/Frameworks/BGHUDAppKit.framework/Versions/A/Resources/BGHUDAppKitPlugin.ibplugin/Contents/MacOS/BGHUDAppKitPlugin
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-8.0/bin/bugpoint
...
DEBUG: Ignoring loadcommand containing @rpath in /opt/local/libexec/llvm-9.0/lib/libRemarks.dylib
DEBUG: Missing architecture i386 in file /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
DEBUG: Missing architecture i386 in file outside prefix referenced from /opt/local/share/cmake-3.19/Modules/Internal/CPack/CPack.OSXScriptLauncher.in
DEBUG: skipping ppc in /opt/local/share/cmake-3.19/Modules/Internal/CPack/CPack.OSXScriptLauncher.in since this system can't run it anyway
--->  No broken files found.
--->  No broken ports found.

[jmroot (Joshua Root)]

In 23f2aa398feac628e5762b604368ba958d705431/macports-base (master):

check runtime availability of _dyld_shared_cache_contains_path

Closes: #61540

[krotalias]

Attaching crash report from #62225, which seems to point to "macho_parse_file", indeed:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   ???                             000000000000000000 0 + 0
1   machista.dylib                  0x000000010c20157f macho_parse_file + 127
2   machista.dylib                  0x000000010c20605d _wrap_parse_file + 157
3   libtcl8.5.dylib                 0x000000010b0267fd TclEvalObjvInternal + 1098
4   libtcl8.5.dylib                 0x000000010b062bb6 TclExecuteByteCode + 6542
5   libtcl8.5.dylib                 0x000000010b06961b TclCompEvalObj + 211

[krotalias]

Crash log file.

[krotalias]

I must add that this problem only appeared after installing

Security Update 2021-001 Catalina

​https://support.apple.com/en-us/HT212147

[krotalias]

Well, I fixed it myself.

It turned out that I had in my problematic computer, into directory /opt/local/libexec/macports/lib/machista1.0,

-r--r--r--  1 root  admin  78656 Nov 15 17:10 machista.dylib

However, I also have two other Catalina systems working perfectly. Then I copied their machista over this one:

-r--r--r--   1 root  wheel  78552 Nov 15 17:53 machista.dylib

Problem gone. rev-upgrade working again.

Maybe macports released a junk dylib that was replaced a few minutes later?

I will never know...

[jmroot (Joshua Root)]

The reason for the problem is in comment:4 and the commit referenced in comment:8 has fixed it in master. Systems that installed from the .pkg wouldn't see the issue, only ones that selfupdated with Xcode 12. Copying the .dylib from another system is a slightly more involved workaround than strictly necessary but I guess it's fine.