I recently had to upgrade my Intel Mac Mini to a current-generation M2 Mini. I did not migrate data or apps over to the new machine. I did a fresh install of Roon, and then “restored” my database from a backup from the old computer.
Knock on wood, it has been solid so far. I’ve had some crashes of the front-end app on my laptop, but the server itself has worked well. I hope I’m not jinxing myself.
Hi,
does it work now? Makes it sense to retrial roon?
Thanks
Henri
Something else
I am experiencing freezes or crashes
Crash of roon server @ Apple Mac mini M1
Hi everyone,
@Henri_Hoffmann has submitted a crash report and accompanying description matching the symptoms of this thread. This one has eluded us for some time, despite an ongoing investigation. Everyone here deserves a fix and we’ve dedicated resources to pin one down.
@jamiesmithnc, @Michael_Kobb, if you’re still seeing this on the latest build, we’d like to activate diagnostics for your accounts and possibly request a copy of your RoonServer database, should you agree to upload it for our QA team.
My last crash was ~5 hours ago, but I updated shortly after that. I’ll keep an eye on it and if it happens again I’ll let you know.
@connor, since I replaced my Intel Mac Mini with an Apple Silicon M2 Mac Mini, I have not had crashing issues. Knock wood!
I had another .NET ThreadPool Worker crash overnight. here’s a snippet of the console log
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process: RoonAppliance [4614]
Path: /Applications/Roon.app/Contents/RoonServer.app/Contents/RoonAppliance.app/Contents/MacOS/RoonAppliance
Identifier: com.roon.RoonAppliance
Version: 1.0 (1.0)
Code Type: X86-64 (Native)
Parent Process: RoonServer [4474]
User ID: 502
Date/Time: 2024-04-11 03:20:52.8810 -0400
OS Version: macOS 14.4.1 (23E224)
Report Version: 12
Bridge OS Version: 8.4 (21P4222)
Anonymous UUID: B1953D07-DEE7-B54E-48C3-624D643E112C
Time Awake Since Boot: 720000 seconds
System Integrity Protection: enabled
Crashed Thread: 55 .NET ThreadPool Worker
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process: RoonAppliance [4614]
Application Specific Information:
abort() called
...
Thread 55 Crashed:: .NET ThreadPool Worker
0 libsystem_kernel.dylib 0x7ff80761314a __pthread_kill + 10
1 libsystem_pthread.dylib 0x7ff80764bebd pthread_kill + 262
2 libsystem_c.dylib 0x7ff807571a39 abort + 126
3 libcoreclr.dylib 0x104c3b752 PROCAbort + 50
4 libcoreclr.dylib 0x104c3b680 PROCEndProcess(void*, unsigned int, int) + 320
5 libcoreclr.dylib 0x104db12e9 EEPolicy::HandleFatalStackOverflow(_EXCEPTION_POINTERS*, int) + 761
6 libcoreclr.dylib 0x104e82d6e HandleHardwareException(PAL_SEHException*) + 542
7 libcoreclr.dylib 0x104c08bbb SEHProcessException(PAL_SEHException*) + 315
8 libcoreclr.dylib 0x104c42fd9 PAL_DispatchException + 137
9 libcoreclr.dylib 0x104c42c63 PAL_DispatchExceptionWrapper + 10
10 dyld 0x7ff807309f20 invocation function for block in dyld3::MachOLoaded::getSlide() const + 47
11 dyld 0x7ff8072bc07f dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 249
12 dyld 0x7ff807309be9 dyld3::MachOLoaded::getSlide() const + 127
13 dyld 0x7ff80730a4c0 invocation function for block in dyld3::MachOLoaded::findSectionContent(char const*, char const*, unsigned long long&, bool) const + 159
14 dyld 0x7ff807305bcf invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 543
15 dyld 0x7ff8072bc07f dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 249
16 dyld 0x7ff807304d0c dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 176
17 dyld 0x7ff80730a400 dyld3::MachOLoaded::findSectionContent(char const*, char const*, unsigned long long&, bool) const + 118
18 dyld 0x7ff8072f0710 dyld4::APIs::_dyld_find_unwind_sections(void*, dyld_unwind_sections*) + 280
19 libunwind.dylib 0x7ff8148a8045 libunwind::UnwindCursor<libunwind::LocalAddressSpace, libunwind::Registers_x86_64>::setInfoBasedOnIPRegister(bool) + 101
20 libunwind.dylib 0x7ff8148ac156 unw_set_reg + 150
21 libcoreclr.dylib 0x104c08fa4 PAL_VirtualUnwind + 148
22 libcoreclr.dylib 0x104e91b1f LazyMachState::unwindLazyState(LazyMachState*, MachState*, unsigned int, int, HostCallPreference) + 271
23 libcoreclr.dylib 0x104cb68db HelperMethodFrame::InsureInit(bool, MachState*, HostCallPreference) + 171
24 libcoreclr.dylib 0x104cb6822 HelperMethodFrame::GetFunction() + 18
25 libcoreclr.dylib 0x104d2ca4b StackFrameIterator::ProcessCurrentFrame() + 123
26 libcoreclr.dylib 0x104d2e204 StackFrameIterator::NextRaw() + 1476
27 libcoreclr.dylib 0x104d2ccb8 StackFrameIterator::Filter() + 88
28 libcoreclr.dylib 0x104d2c46b StackFrameIterator::Init(Thread*, Frame*, REGDISPLAY*, unsigned int) + 443
29 libcoreclr.dylib 0x104d2c0ec Thread::StackWalkFramesEx(REGDISPLAY*, StackWalkAction (*)(CrawlFrame*, void*), void*, unsigned int, Frame*) + 268
30 libcoreclr.dylib 0x104d2c5e3 Thread::StackWalkFrames(StackWalkAction (*)(CrawlFrame*, void*), void*, unsigned int, Frame*) + 211
31 libcoreclr.dylib 0x104dbcbc9 ScanStackRoots(Thread*, void (*)(Object**, ScanContext*, unsigned int), ScanContext*) + 313
32 libcoreclr.dylib 0x104dbc9e9 GCToEEInterface::GcScanRoots(void (*)(Object**, ScanContext*, unsigned int), int, int, ScanContext*) + 249
33 libcoreclr.dylib 0x104f026b2 WKS::gc_heap::mark_phase(int, int) + 818
34 libcoreclr.dylib 0x104efefed WKS::gc_heap::gc1() + 909
35 libcoreclr.dylib 0x104f09f2e WKS::gc_heap::garbage_collect(int) + 2110
36 libcoreclr.dylib 0x104ef9eda WKS::GCHeap::GarbageCollectGeneration(unsigned int, gc_reason) + 1082
37 libcoreclr.dylib 0x104efc07f WKS::gc_heap::try_allocate_more_space(alloc_context*, unsigned long, unsigned int, int) + 719
38 libcoreclr.dylib 0x104f24820 WKS::GCHeap::Alloc(gc_alloc_context*, unsigned long, unsigned int) + 160
39 libcoreclr.dylib 0x104dc1ad8 AllocateObject(MethodTable*) + 200
40 libcoreclr.dylib 0x104dded1d JIT_New(CORINFO_CLASS_STRUCT_*) + 141
41 ??? 0x10cdc2c7c ???
42 ??? 0x10cdc273c ???
...
507 ??? 0x111bd2e4f ???
508 ??? 0x111c1cc53 ???
509 ??? 0x111c1c805 ???
510 ??? 0x111bd1adb ???
511 ??? 0x111bd2e4f ???
And another this morning @connor
Four more in the past two days, on the 1401 build.
EDIT because I’m not allowed a new reply.
@connor I had hopes that the 1407 build would have helped but just had another .NET crash. Did you ever activate diagnostics as you mentioned a month ago? My crash log shows it hit today, May 1, at 11:30am EDT.
Note that while Roon is open it’s not playing anything.
There hasn’t been an update on this thread for a while, but at present Roon is unusable for me as I’m getting these thread worker crashes every few minutes on two different systems.
is a Mac mini M1 (2020) running the latest macOS Sonoma 14.5
is a MacBook M1(2020) running Ventura 13.6.7
Both running the latest Roon software - I’ve done a complete reinstallation today on system 1 above, and then a new server installation on system 2 to see whether that made any difference - however both continue to crash as described in this thread.
I’ve been having problems with this for many months with variable frequency but I can see from the discussion here that this problem has been around for almost two years. Most of the listening has been streamed radio and tracks from qobuz.
Are you running the full app on the M1 Mac mini or just the server app?
I have been running just the server app on my M1 Mac mini and have never seen this problem. If you are running the full app, switch over to the server app and see how that works.
There are no separate full app and server app installations anymore. Just one app that installs both the GUI and the server, and then you run the one(s) you want. But it would be interesting how @David-Salmon runs it, GUI and server on the same machine or separate machines, and which one it is that crashes.
Adding my voice to this problem. Running Roon build 1445 and Mac OS Sonoma 14.6 on a Mac Mini M2. So far today, according to Crash Reports in Console, RoonAppliance has crashed 12 times. Each one with
Crashed Thread: 55 .NET ThreadPool Worker
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process: RoonAppliance [98042]
I am more than happy to provide any logs etc to help diagnose. This problem seems to have been around for a very long time!
I should add that I have actually not used Roon at all today. It’s just sitting there idle.
Not only am I getting a number of crashes a day, but now RoonAppliance is constantly consuming between 50% and 95% CPU. I’ve restarted it, rebooted, and it continues to do it, with absolutely nothing playing. @connor I think we all deserve some more and better feedback on these problems. Roon is just not cutting it, at least on Mac, and we’ve all paid good money…
A few weeks back when I posted my original message I had tried installing the server only version as I had kept an old image, but it didn’t help.
However, things have changed a lot over the last few weeks with two (I think) new versions of Roon and a MacOs upgrade to Sonoma on the mini. I haven’t had a crash for a week or two now and for me Roon is back to being stable and reliable from a position of being unusable. I’ll keep a close eye on this status and I hope it continues !
I tend to leave the appliance running on the Mac mini and control it from roon client apps on iPhones, iPads and MacBooks, any of six or seven devices between my wife and I. I might occasionally use the client interface on the Mac mini itself if I happen to be connected to it (screen sharing from a MacBook) and checking something.
CORRECTION - ahhh… I’ve just checked and I’m actually on Sequoia 15.0 on the mini and NOT Sonoma as I wrote in my previous message - too many changes recently !
Hello everyone,
It’s been a while since there was any activity on this thread. Could you please confirm if this issue is still ongoing or if it has been resolved for those affected?
I’ll set a topic timer for the thread to auto-close in two weeks, however, if you are still experiencing this behavior, please let us know, and we’ll be happy to re-evaluate. Thank you!
Mine does seem to have settled. It may have been due to some interaction with the Homebridge software running on the same Mac. That software runs its own mdns instance, with a choice between Ciao and Bonjour HAP. One option is to nominate the network interface used for this, with the default being Auto. With this setting, mdns traffic seemed to increase, and the CPU utilisation of RoonAppliance skyrocketed. And maybe it was crashing with this setup. I changed the network interface for mdns in Homebridge so it’s now fixed to the Ethernet port, and those problems went away.
Does Roon run some sort of mdns implementation of its own that may conflict?
I continue to be perplexed by Roon’s steady state CPU usage though (even when the above is fixed). It’s always been this way for me, and I’ve confirmed the behaviour with other users. The CPU usage spikes every 20 to 30 seconds, up to 90% of a core. No music is playing, and no clients are connected. What can it possibly be constantly doing? It looks as though the network activity attributed to RoonAppliance also spikes at the same time.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.