watchman: trace trap because of libunwind installed by the libunwind port

[phiz118]

~ % sudo port install watchman                        
--->  Computing dependencies for watchman
--->  Fetching archive for watchman
--->  Attempting to fetch watchman-2023.11.13.00_2.darwin_23.arm64.tbz2 from https://packages.macports.org/watchman
--->  Attempting to fetch watchman-2023.11.13.00_2.darwin_23.arm64.tbz2.rmd160 from https://packages.macports.org/watchman
--->  Installing watchman @2023.11.13.00_2
--->  Activating watchman @2023.11.13.00_2
--->  Cleaning watchman
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.
~ % watchman
zsh: trace trap  watchman

Apple M1 Max
Sonoma 14.3

[ryandesign (Ryan Carsten Schmidt)]

A quick search of "trace trap" suggests it means the program received a SIGTRAP signal, and that this would occur if there were an unhandled exception.

I'm not sure if this situation would generate a crash log in ~/Library/Logs/DiagnosticReports. If it does, please attach it.

[raxod502-plaid (Radon Rosborough)]

crash log

[raxod502-plaid (Radon Rosborough)]

I experience this issue as well, also Sonoma 14.3.1 on M1 with watchman @2023.11.13.00_2. I can confirm that this situation *does* generate a crash log in the location described, and have attached it.

[mrdomino (Jōshin)]

I ran into this too, and it seems that watchman installed via homebrew does not have this issue. (I installed homebrew, ran brew install watchman, and then reran the failing command and it worked.)

This is on Sonoma 14.3 M1.

[kencu (Ken)]

it looks like it is dying in the ancient libunwind from the libunwind port that we should not have installed on any current system:

% port -v installed libunwind
The following ports are currently installed:
  libunwind @5.0.1_0+universal (active) requested_variants='' platform='darwin 23' archs='arm64 x86_64' date='2024-02-15T17:45:23-0800'

% otool -L /opt/local/bin/watchman | grep unwind
	/opt/local/lib/libunwind.1.dylib (compatibility version 1.0.0, current version 5.0.1)

% lldb watchman
(lldb) target create "watchman"
Current executable set to '/opt/local/bin/watchman' (arm64).
(lldb) r
Process 82836 launched: '/opt/local/bin/watchman' (arm64)
Process 82836 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x191ccba6c)
    frame #0: 0x0000000191ccba6c libunwind.dylib`_Unwind_GetIP + 244
libunwind.dylib`:
->  0x191ccba6c <+244>: brk    #0xc471
    0x191ccba70 <+248>: mov    x0, x16
    0x191ccba74 <+252>: ldp    x29, x30, [sp, #0x10]
    0x191ccba78 <+256>: ldp    x20, x19, [sp], #0x20
Target 0: (watchman) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BREAKPOINT (code=1, subcode=0x191ccba6c)
  * frame #0: 0x0000000191ccba6c libunwind.dylib`_Unwind_GetIP + 244
    frame #1: 0x000000018540bc7c libc++abi.dylib`__gxx_personality_v0 + 588
    frame #2: 0x0000000100a6d144 libunwind.1.dylib`unwind_phase2 + 140
    frame #3: 0x0000000100a6d1d0 libunwind.1.dylib`_Unwind_Resume + 52
    frame #4: 0x000000010010cd84 watchman`json_load_file(char const*, unsigned long) + 620
    frame #5: 0x000000010007aa5c watchman`cfg_load_global_config_file() + 152
    frame #6: 0x00000001000830b4 watchman`main + 104
    frame #7: 0x00000001850d10e0 dyld`start + 2360

[kencu (Ken)]

forcing libunwind out of the installed ports, stripping the dep from the ports that depending on it, and then rebuilding everything that is then broken fixes watchman:

% port -v installed libunwind | grep active
% otool -L /opt/local/bin/watchman | grep unwind
% watchman
 -- no error --

[kencu (Ken)]

OK, so it's time to get this libunwind headache dealt with, clearly.

As the libunwind port is absolutely needed on 10.6 and less, and (AFAICT) will never be needed on 10.7+, the simplest solution is to have the libunwind port be a dummy on 10.7+.

Everything that has then been built that links against the libunwind port will then be broken and have to be rebuilt.

[kencu (Ken)]

looking at that backtrace again, two different libunwind dylibs seem to be being accessed…. that is hard to tell for sure, but if that is the case, that could certainly lead to a crash.

There is no guarantee that different versions of libunwind are compatible with each other… an object created in one version would never expect to work when accessed by a different version.

There is a way to do dylib tracing if anyone really needs to know this…. but the solution herevis still to get rid of the libunwind port on all newer systems.

[kencu (Ken)]

There was a suggestion to sequester libunwind for all systems, instead of making it a dummy port on newer systems.

I think Jeremy tried that before and ran into trouble ( see ​https://github.com/macports/macports-ports/commit/ad2539dbdf068dcfdd21e3bed2eaf2bf7714e64b).

Also that means the includes and link paths would have to be fiddled with, but only on older systems where you want libunwind…. just seems like too much trouble.

Could there ever be some reason to install a newer libunwind on 10.7 or newer? Well, maybe, but.. seems unlikely at present.

[Schamschula (Marius Schamschula)]

I just ran into this trying to upgrade octave to version 9.1.0. libunwind snuck in via GraphicsMagick and caused a trap 5 error. See: ​https://savannah.gnu.org/bugs/index.php?65468