- Device model (e.g. 2020 iPad Air 4th Gen): Macbook Air
- Version of operating system (e.g. macOS 14.4.1): macOS Tahoe Version 26.4 (25E246)
- Version of djay (e.g. 5.1.2): djay Version 5.6.4
- Hardware/controllers used (e.g. Reloop Mixon 8 Pro): FLX10
- Hardware firmware version (e.g. 1.0.1): latest
- Please consider sharing a short video or screenshots to help clarify your issue
Issue Summary
djay Pro crashes unexpectedly with a SIGABRT signal on macOS (Apple Silicon). The crash originates in the Beatport HTTP worker thread due to an unhandled std::system_error thrown during a std::mutex::lock() operation.
Environment
| Property | Value |
|---|---|
| Application | djay Pro (com.algoriddim.djay-iphone-free) |
| Version | 5.6.4 (Build 66070) |
| Operating System | macOS 26.4 (Build 25E246) |
| Hardware | Mac16,13 (Apple Silicon, ARM-64) |
Steps to Reproduce
The exact steps are intermittent, but the crash is consistently tied to Beatport integration:
1.Launch djay Pro with an active Beatport/Beatsource connection.
2.The crash occurs either during track loading, background library refresh, or when the application attempts to re-authenticate (e.g., ARCBeatportSessionManager enableGuestMode).
NOTE: This also has occurred with the Spotify Integration. 
flagging that if djay Pro’s Spotify integration shares the same HTTP worker architecture or mutex patterns, it could be vulnerable to the same class of bug.
Crash Details
•Exception Type: EXC_CRASH (SIGABRT)
•Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6
•Faulting Thread: Thread 33 (Beatport HTTP worker)
RCA
The crash is caused by a failure to acquire a mutex lock in the Beatport HTTP worker thread. The standard library throws a std::system_error (likely due to a double-lock/deadlock attempt or accessing a destroyed mutex object). Because this exception is not caught by a try-catch block, std::terminate() is invoked, which calls abort(), crashing the application.
Key Backtrace Frames (Thread 33)
0 libsystem_kernel.dylib 0x1827185e8 __pthread_kill + 8
1 libsystem_pthread.dylib 0x1827538d8 pthread_kill + 296
2 libsystem_c.dylib 0x18265a790 abort + 148
…
7 libc++.1.dylib 0x1826890a4 std::__1::__throw_system_error[abi:nqe210106](std::__1::error_code, char const*) + 92
8 libc++.1.dylib 0x182689048 std::__1::__throw_system_error(int, char const*) + 32
9 libc++.1.dylib 0x182666028 std::__1::mutex::lock() + 40
10 djay Pro 0x1013d0084 0x100c74000 + 7716996
11 djay Pro 0x1013a657c 0x100c74000 + 7546236
Suggested Fixes
1. Audit Mutex Usage: Review the synchronization logic in the Beatport HTTP worker (around offset 0x1013d0084). Ensure there are no recursive locking attempts on a standard std::mutex and that the mutex object outlives the asynchronous network callbacks.
2.Use RAII: Replace manual lock()/unlock() calls with std::lock_guard or std::unique_lock to ensure exception-safe lock management.
3.Add Exception Handling: Wrap the Beatport HTTP worker logic in a try-catch block to catch std::system_error and handle it gracefully (e.g., by logging the error and failing the specific network request) rather than allowing the entire application to crash.
