Hey guys does anyone know what causes this crash?
Cubase 14-2025-01-25-230000.ips (225.8 KB)
I return to cubase after awhile and return to this crash, was just wondering what triggers it. happens often ; macbook m1 max
Hey guys does anyone know what causes this crash?
Cubase 14-2025-01-25-230000.ips (225.8 KB)
I return to cubase after awhile and return to this crash, was just wondering what triggers it. happens often ; macbook m1 max
A description would help Apple users, instead of making them download and trawl through a crash dump.
The uploaded file contains a detailed crash log that includes exception information, faulting threads, and stack traces. Here’s a summary of the key findings:
EXC_BAD_ACCESS
SIGSEGV
(Segmentation Fault)KERN_INVALID_ADDRESS
at a particular memory address.This indicates that Cubase attempted to access an invalid memory location, which may suggest a pointer authentication failure or memory corruption.
[__NSCFArray objectAtIndex:]
.This points to a possible issue with an array operation (e.g., accessing an index that doesn’t exist or a corrupted array).
Key frames from the stack trace:
-[__NSCFArray objectAtIndex:]
CFArrayGetFirstIndexOfValue
__CFRepositionTimerInMode
__CFRunLoopDoTimer
CFRunLoopRunSpecific
-[NSApplication runModalForWindow:]
This sequence suggests that the crash occurred during an array operation, potentially within a timer callback in the Core Foundation run loop.
Check Plugins:
Reset Preferences:
Update Software:
Reproduce the Issue:
Contact Steinberg Support:
Hi,
The crash is in the Universal Audio Oxide Tape. Please, get in touch with UAD.
Thread 68 Crashed:: Socket
0 uaudio_oxide_tape 0x3f464fda0 boost::asio::detail::timer_queue<boost::asio::time_traits<boost::posix_time::ptime>>::get_ready_timers(boost::asio::detail::op_queue<boost::asio::detail::scheduler_operation>&) + 144
1 uaudio_oxide_tape 0x3f4652e7c boost::asio::detail::kqueue_reactor::run(long, boost::asio::detail::op_queue<boost::asio::detail::scheduler_operation>&) + 1712
2 uaudio_oxide_tape 0x3f4653abc boost::asio::detail::scheduler::do_run_one(boost::asio::detail::conditionally_enabled_mutex::scoped_lock&, boost::asio::detail::scheduler_thread_info&, boost::system::error_code const&) + 400
3 uaudio_oxide_tape 0x3f46537d0 boost::asio::detail::scheduler::run(boost::system::error_code&) + 196
4 uaudio_oxide_tape 0x3f4656d4c boost::asio::io_context::run() + 36
5 uaudio_oxide_tape 0x3f4656afc std::__1::__shared_ptr_emplace<UAThread, std::__1::allocator<UAThread>>::__on_zero_shared_weak() + 1060
6 uaudio_oxide_tape 0x3f46b52e8 UAThread::ThreadProcInternal() + 388
7 uaudio_oxide_tape 0x3f46b5b38 std::__1::thread::thread<void (UAThread::*)(), UAThread*, void>(void (UAThread::*&&)(), UAThread*&&) + 292
8 libsystem_pthread.dylib 0x197a3c2e4 _pthread_start + 136
9 libsystem_pthread.dylib 0x197a370fc thread_start + 8
Hi,
This is thread 0, not the CrashThread, therefore this is not relevant.
I agree, that it is not the crashthread.
It is relevant though as this sequence suggests that the crash occurred during an array operation with the key frame 1. -[__NSCFArray objectAtIndex:]
and points to faulting thread 68 with the * Error: The main thread encountered an “Address size fault” during a call to [__NSCFArray objectAtIndex:]
.
Can surely be ignored if you go directly to thread with id 68 (CrashThread)