[MacPorts] #68658: libarchive: bsdtar crashes with dyld missing symbol

MacPorts noreply at macports.org
Wed Jun 11 20:41:31 UTC 2025


#68658: libarchive: bsdtar crashes with dyld missing symbol
-------------------------+--------------------------
  Reporter:  PerMildner  |      Owner:  tobypeterson
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:
      Port:  libarchive  |
-------------------------+--------------------------

Comment (by ryandesign):

 I'm sorry you've continued to see this! I'd love to get to the bottom of
 it.

 The log shows /usr/bin/tar is being used to extract ports, which is good.

 The crash log says the crash happened at 18:01:32.1954. Your computer is
 so fast that many things happen within that second and MacPorts logs don't
 have subsecond timing. (I filed #72600 to add that.) Here are the things
 that the log shows happened during that second:

 {{{
 % grep -A1 'started at .* 18:01:32' < port_upgrade_outdated.log
 DEBUG: install phase started at Wed Jun 11 18:01:32 CEST 2025
 --->  Installing libxml2 @2.13.8_0
 --
 DEBUG: clean phase started at Wed Jun 11 18:01:32 CEST 2025
 --->  Cleaning libxml2
 --
 DEBUG: activate phase started at Wed Jun 11 18:01:32 CEST 2025
 DEBUG: Executing org.macports.activate (libxml2)
 --
 DEBUG: deactivate phase started at Wed Jun 11 18:01:32 CEST 2025
 DEBUG: elevating privileges for deactivate: euid changed to 0, egid
 changed to 0.
 --
 DEBUG: clean phase started at Wed Jun 11 18:01:32 CEST 2025
 --->  Cleaning libxml2
 --
 DEBUG: load phase started at Wed Jun 11 18:01:32 CEST 2025
 DEBUG: Executing org.macports.load (libxml2)
 --
 DEBUG: clean phase started at Wed Jun 11 18:01:32 CEST 2025
 --->  Cleaning libxml2
 --
 DEBUG: archivefetch phase started at Wed Jun 11 18:01:32 CEST 2025
 --->  Fetching archive for libarchive
 --
 DEBUG: install phase started at Wed Jun 11 18:01:32 CEST 2025
 --->  Installing libarchive @3.8.1_0
 --
 DEBUG: clean phase started at Wed Jun 11 18:01:32 CEST 2025
 --->  Cleaning libarchive
 --
 DEBUG: activate phase started at Wed Jun 11 18:01:32 CEST 2025
 DEBUG: Executing org.macports.activate (libarchive)
 --
 DEBUG: deactivate phase started at Wed Jun 11 18:01:32 CEST 2025
 DEBUG: elevating privileges for deactivate: euid changed to 0, egid
 changed to 0.
 --
 DEBUG: clean phase started at Wed Jun 11 18:01:32 CEST 2025
 --->  Cleaning libarchive
 --
 DEBUG: load phase started at Wed Jun 11 18:01:32 CEST 2025
 DEBUG: Executing org.macports.load (libarchive)
 --
 DEBUG: clean phase started at Wed Jun 11 18:01:32 CEST 2025
 --->  Cleaning libarchive
 --
 DEBUG: archivefetch phase started at Wed Jun 11 18:01:32 CEST 2025
 --->  Fetching archive for cmake
 }}}

 One of the things that happened was that libarchive, which provides
 /opt/local/bin/bsdtar, got updated. That seems relevant.

 I suspect the invocation of `bsdtar` that causes the crash happens on
 these lines in MacPorts base, or one of the other places that does
 something similar:

 https://github.com/macports/macports-
 base/blob/093d55c49db68404a787b912d19853e97be57525/src/registry2.0/portimage.tcl#L494-L515

 Before extracting, MacPorts base runs `bsdtar` to see if it supports HFS
 compression. The `tar` included with old macOS versions does not include
 HFS compression, but if you install the libarchive port, then all ports
 use its `bsdtar` so that the files a port installs are compressed.

 I was unable to reproduce the problem by running `sudo port -nb upgrade
 --force --no-rev-upgrade libarchive` on my x86_64 macOS 12 machine. I used
 CrashReporterPrefs to enable showing the dialog but none appeared and no
 logs were generated in /Library/Logs/DiagnosticReports nor
 ~/Library/Logs/DiagnosticReports. If you run that command a few times,
 does the crash occur each time, or sometimes, or not at all?

 It still doesn't seem like the problem should be happening. Activation and
 deactivation affect all of a port's files. Either MacPorts `bsdtar` and
 its `liblzma` should both exist or they both should not.

 It almost feels like a variation of a filesystem cache bug we've already
 encountered (#67336). In this case, while activating libarchive, it seems
 like the MacPorts `bsdtar` should not be on disk anymore since the
 libarchive port has already been deactivated, but for some reason it still
 exists.

-- 
Ticket URL: <https://trac.macports.org/ticket/68658#comment:20>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list