Fixing TASCAM US-2x2/US-4x4 Settings Panel Crashes on Apple Silicon

Jul 03, 26

The Settings Panel for my TASCAM US-4x4 audio interface was crashing immediately on launch on my M1 MacBook Pro (macOS Sonoma). No dialog, no error — just an instant crash report from macOS. Here’s how I tracked it down and fixed it.

The crash report

macOS’s crash reporter pointed at EXC_BAD_ACCESS (SIGSEGV) in a background QThread. The relevant frames:

Thread 7 Crashed:: QThread
...
QSslCertificate::fromData(QByteArray const&, QSsl::EncodingFormat)
QSslConfiguration::QSslConfiguration()
QNetworkAccessManager::createRequest(...)
QNetworkAccessManager::get(QNetworkRequest const&)
UpdateInformation::downloadInformation() + 303

Translation: on launch, the app’s “check for update” feature (UpdateInformation::downloadInformation()) tries to make an HTTPS request to TASCAM’s servers, and it dies while setting up the SSL config for that request. The Settings Panel is built on Qt 5.4.1 — a build from roughly 2015 — running under Rosetta 2.

The binary image list showed it was loading libssl.3.dylib / libcrypto.3.dylib from a Homebrew OpenSSL 3.6.0 install. Qt doesn’t statically link OpenSSL (licensing reasons); it dlopens whatever SSL library it finds on the system at runtime. My first guess: an ABI mismatch between what this decade-old Qt build expects and modern OpenSSL 3.

Debugging

Step 1 — remove the suspect library and see what happens. I unlinked Homebrew’s OpenSSL 3 (brew unlink openssl@3) and relaunched. Same instant crash, but no crash report this time. Since the graphical crash reporter only fires on certain signals, I ran the binary directly from Terminal to see stderr in real time:

/Applications/US-2x2_US-4x4_SettingsPanel.app/Contents/MacOS/US-2x2_US-4x4_SettingsPanel

That surfaced the real problem:

qt.network.ssl: QSslSocket: cannot resolve SSLeay
qt.network.ssl: QSslSocket: cannot resolve SSLv3_client_method
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_num_locks
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_locking_callback
qt.network.ssl: QSslSocket: cannot resolve sk_push
...
Segmentation fault: 11

SSLeay, SSLv3_client_method, and the CRYPTO_*_callback/sk_* stack functions are all pre-1.1 OpenSSL API — this Qt build was written against OpenSSL 1.0.x. Neither Homebrew’s OpenSSL 3 nor Apple’s own (deprecated, stubbed-out) system libssl provide these symbols. Qt fails to resolve them, then — this is the actual bug — calls through the unresolved (effectively null) function pointers anyway instead of bailing out cleanly. That null-pointer call is the segfault.

Step 2 — try disabling the network path entirely. A community fix exists for a sibling TASCAM product (the US-16x08, built on the same Qt5.4 codebase) that avoids an identical-looking crash by deleting the app’s Contents/PlugIns/bearer folder (Qt’s network bearer/interface-monitoring plugins) and re-signing the app:

sudo rm -rf "/Applications/US-2x2_US-4x4_SettingsPanel.app/Contents/PlugIns/bearer"
sudo codesign --remove-signature "/Applications/US-2x2_US-4x4_SettingsPanel.app"
sudo codesign --force --deep --sign - "/Applications/US-2x2_US-4x4_SettingsPanel.app"

This didn’t help for the US-2x2/US-4x4 build — UpdateInformation::downloadInformation() still ran and the app still crashed (this time as a Bus error: 10 instead of a segfault, same root cause: jumping through a bad pointer).

Step 3 — give it the OpenSSL it actually wants. Rather than fight Qt’s broken error handling, the real fix is to make sure a genuine OpenSSL 1.0.2 library is available for it to dlopen. Homebrew dropped openssl@1.0 from core years ago, but the rbenv/homebrew-tap still maintains a working formula with Apple Silicon support:

# install a real, working legacy OpenSSL 1.0.2
arch -x86_64 /usr/local/bin/brew install rbenv/tap/openssl@1.0

# it's keg-only, so symlink it where Qt's dlopen will actually find it
ln -sf /usr/local/opt/openssl@1.0/lib/libssl.1.0.0.dylib   /usr/local/lib/libssl.1.0.0.dylib
ln -sf /usr/local/opt/openssl@1.0/lib/libcrypto.1.0.0.dylib /usr/local/lib/libcrypto.1.0.0.dylib

With those in place, Qt resolves the legacy symbols for real (instead of failing and calling null pointers), the update check either succeeds or fails gracefully over the network, and the Settings Panel opens normally.

Why this happens at all

Two things had to line up for this crash to happen:

  1. Apple removed OpenSSL from the public system SDK starting with macOS 10.11 — there’s no real system libssl/libcrypto to fall back on anymore, just a deprecated, non-functional stub.
  2. This particular Qt 5.4.1 build targets the pre-1.1 OpenSSL API (SSLeay, SSLv3_client_method, manual locking callbacks), which was removed from OpenSSL over five years ago. Any system that doesn’t happen to have a matching legacy library sitting around will hit this.

TASCAM hasn’t shipped an updated build of this Settings Panel that addresses it, so until they do, the workaround above is the fix.

The automated version

I packaged the diagnosis and fix into a small repo with a script that checks for the right dependencies and applies the fix automatically: Tascam_US-2x2_US-4x4_SettingsPanel_fix.

If you hit this same crash on a different TASCAM Qt-based utility, the same root cause (and likely the same fix) applies — check your own crash report for QSslCertificate/QSslConfiguration frames and a QThread calling into QNetworkAccessManager to confirm.