Very frequent crashes on iOS and OSX

The Roon app frequently (several times daily) crashes for me. I tried to include my crash log here, but it’s too long (about 35k).

I tried writing to support, but was referred to the forum, so…

Hi Steve,
Someone from the Roon team, @eric, @vova, @mike, will pick this up and get back to you.

1 Like

Hi @Steve_Kalkwarf ---- Thank you for the feedback and apologies for the inconvenience here. I will be contacting you shortly to gather logs from you so our developers can take a closer look into this issue. Thanks!

-Eric

I mentioned this in another post, but nobody responded. This time I have a crashlog, but much like my iOS crashes, it’s too big to post.

@Support ?

Steve, I’ve moved your post into the existing topic to keep the history together.
Did @Eric not get back to you? Maybe it slipped off his to do list.

Fairly frequently, I go to see what’s playing, or pause a player, and I can’t find the Roon icon in the dock. Digging through the system logs, I find:

7/21/16 9:49:49.901 AM com.apple.xpc.launchd[1]: (com.roon.Roon.31072[1364]) Service exited with abnormal code: 5

but no additional data. What can I do to troubleshoot this?

Unrelated, but as long as I’m here:

7/21/16 9:54:24.011 AM Roon[3076]: WARNING: The Gestalt selector gestaltSystemVersion is returning 10.9.6 instead of 10.11.6. This is not a bug in Gestalt -- it is a documented limitation. Use NSProcessInfo's operatingSystemVersion property to get correct system version number.
Call location:
7/21/16 9:54:24.014 AM Roon[3076]: 0   CarbonCore                          0x00007fff88c1b6df ___Gestalt_SystemVersion_block_invoke + 113
7/21/16 9:54:24.014 AM Roon[3076]: 1   libdispatch.dylib                   0x00007fff93d0a40b _dispatch_client_callout + 8
7/21/16 9:54:24.014 AM Roon[3076]: 2   libdispatch.dylib                   0x00007fff93d0a303 dispatch_once_f + 67
7/21/16 9:54:24.014 AM Roon[3076]: 3   CarbonCore                          0x00007fff88ba7fbc _Gestalt_SystemVersion + 987
7/21/16 9:54:24.014 AM Roon[3076]: 4   CarbonCore                          0x00007fff88ba77d0 Gestalt + 139
7/21/16 9:54:24.014 AM Roon[3076]: 5   libHIDRemoteNative.dylib            0x00000001134abb6d +[HIDRemote isCandelairInstallationRequiredForRemoteMode:] + 45
7/21/16 9:54:24.014 AM Roon[3076]: 6   ???                                 0x000000011a05bbac 0x0 + 4731550636

This one (from the same time period - 15 days ago) looks related as well, so I’ve also moved it here.

I’ll leave a @support flag just in case @Eric is not available right now.

I’ve provided detail on the iOS/iPhone crashes, but not the Mac crashes. It made sense to me to keep them separate since they’re separate operating systems.

My thought was as they happened at the same time there might be some correlation between the events.
Let’s see what the Roon devs can find.

Hi @Steve_Kalkwarf ----- Thank you for all of your continued feedback and my apologies for the slow response here. Our developers are still trying to reproduce the issue in house to no avail. Have you noticed any patterns in behavior that maybe leading up to these crashes?

-Eric

Not particularly. If I had a reproducible case, I’d share.

I would be willing to wager that more than half the time it’s almost immediately after a device (Mac or iPhone) has woken from sleep, and I’ve tried to interact with Roon. Here’s the crashing thread from my most recent episode:

Thread 9 Crashed:
0   libsystem_kernel.dylib        	0x00007fff8d4f8f06 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff8aca34ec pthread_kill + 90
2   libsystem_c.dylib             	0x00007fff8e8386df abort + 129
3   Roon                          	0x000000010be0f033 mono_handle_native_sigsegv + 611
4   libsystem_platform.dylib      	0x00007fff8bca152a _sigtramp + 26
5   ???                           	0x0000000000000002 0 + 2
6   libsystem_c.dylib             	0x00007fff8e8386df abort + 129
7   libxammac.dylib               	0x000000010f74db86 log_callback(char const*, char const*, char const*, int, void*) + 70
8   Roon                          	0x000000010bfaa270 monoeg_g_log + 208
9   Roon                          	0x000000010beffff2 poll_event_wait + 434
10  Roon                          	0x000000010befee01 selector_thread + 1089
11  Roon                          	0x000000010befafb6 start_wrapper + 454
12  Roon                          	0x000000010bfa35ee inner_start_thread + 206
13  libsystem_pthread.dylib       	0x00007fff8aca099d _pthread_body + 131
14  libsystem_pthread.dylib       	0x00007fff8aca091a _pthread_start + 168
15  libsystem_pthread.dylib       	0x00007fff8ac9e351 thread_start + 13

If it helps, I’d be willing to run a build with additional logging enabled.

I’ve been getting an occasional crash using the ios app on my iphone, but it doesn’t look like a crash log is being added to the normal place in the settings app. I haven’t spotted any pattern to the behaviur as yet, if I do I will let you know.

I mostly use an ipad, which has probably only crashed on a couple of occasions since I joined up about 4 weeks ago. It feels the more stable of the 2 apps.

Happy to help test new app builds if you are looking for beta testers (I already beta test for Naim)

Nick

The Mac OS crashes are elusive, as the app just disappears from the Dock, and no crash report is generated. To try to catch it in the act, I attached to Roon with a debugger, and let it run. Unfortunately, no symbols, but it looks like the app is dereferencing a null pointer

`(lldb) attach Roon
Process 3494 stopped

  • thread #1: tid = 0x505ac3, 0x00007fff8d4f2f72 libsystem_kernel.dylibmach_msg_trap + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00007fff8d4f2f72 libsystem_kernel.dylibmach_msg_trap + 10
    libsystem_kernel.dylib`mach_msg_trap:
    -> 0x7fff8d4f2f72 <+10>: retq
    0x7fff8d4f2f73 <+11>: nop

libsystem_kernel.dylib`mach_msg_overwrite_trap:
0x7fff8d4f2f74 <+0>: movq %rcx, %r10
0x7fff8d4f2f77 <+3>: movl $0x1000020, %eax ; imm = 0x1000020

Executable module set to “/Applications/Roon.app/Roon”.
Architecture set to: x86_64h-apple-macosx.
(lldb) c
Process 3494 resuming
Process 3494 stopped

  • thread #27: tid = 0x50854f, 0x000000011aeca467, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x000000011aeca467
    -> 0x11aeca467: cmpl $0x0, (%rax)
    0x11aeca46a: movabsq $0x11659ee60, %r11 ; imm = 0x11659EE60
    0x11aeca474: callq *%r11
    0x11aeca477: movq %rax, %rcx
    thread #31: tid = 0x508b79, 0x000000011ae9a4d1, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x000000011ae9a4d1
    -> 0x11ae9a4d1: cmpl $0x0, (%rax)
    0x11ae9a4d4: movabsq $0x1171f2590, %r11 ; imm = 0x1171F2590
    0x11ae9a4de: callq *%r11
    0x11ae9a4e1: movq %rax, %r14
    (lldb) bt
  • thread #27: tid = 0x50854f, 0x000000011aeca467, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    • frame #0: 0x000000011aeca467
      frame #1: 0x0000000113f76a4d
      (lldb)
      `

Something just occurred to me. I’m often going back and forth between the iPhone and Mac, controlling or observing the same player. I wouldn’t expect that to matter, but maybe that’s the difference between how I use the remotes, and how others are using Roon?