Kernel panic on macOS due to Roon Remote memory growth (ref#OLLI53)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Roon Remote on macOS grew to ~73 GB memory footprint and caused a kernel panic

On 20 September my MacBook M1 Pro kernel panicked (watchdog timeout) after the Roon Remote app used up all available memory. The macOS logs show Roon as the largest process by a wide margin, with a footprint of about 73 GB on a machine with 16 GB of RAM.

Setup:
- Roon Remote: 2.71 (build 1683)
- Roon Core: 2.71 (build 1683), running on a Debian server
- Mac: 14" MacBook Pro, M1 Pro, 16 GB RAM (MacBookPro18,3)
- macOS 15.7.7 (24G720)

What the logs show:
- 17 September: Roon Remote footprint about 4.0 GB.
- 19 September, 20:00: about 4.3 GB. macOS also logged a CPU resource report for Roon at this point. It was averaging 60% CPU over roughly two and a half minutes while in the background and with the Mac idle and on battery.
- The Mac went to sleep shortly after and woke at about 08:35 on 20 September.
- 13:12 to 13:17 on 20 September: a series of JetsamEvent reports (reason: vm-compressor-space-shortage) show Roon at about 73 to 74 GB.
- About 15:14: kernel panic (watchdog timeout), with the panic log showing the memory compressor at 100% of its limit and 31 swap files.

So memory grew slowly over several days and then jumped by nearly 70 GB within about four and a half hours of the Mac waking from sleep.

This isn't the first time. About a week earlier I noticed Roon was sluggish and using a huge amount of memory, probably in the same 60 to 70 GB range, and I quit it before it brought the system down.

Is this a known issue with the Remote on macOS, or have there been other reports of similar memory growth?

Tell us about your home network

· UniFi network: UCG Fiber gateway, USW-Pro-Max-24-PoE core switch with Flex switches downstream, six UniFi APs. The Core (Debian server) and the Mac are on the same subnet. The Mac was connected by wired Ethernet through a USB-C hub.

2

Hey @discomoo,

Thanks for the detailed report, the panic log timeline and the server logs line up well, and we think we can see what’s feeding this.

Your Roon Server is healthy: steady ~3 GB, no leak, nothing unusual at 15:14 when the Mac panicked. The problem is upstream of the Remote, but it isn’t the server’s memory, it’s the volume of updates the server is being made to generate.

Your iPad (192.168.y.159) and iPhone (192.168.y.204) are each running a RAATServer that accepts the server’s control connection and then immediately drops it. Roon Server retries with no backoff, so it spins:

[RaatServer localhost @ 192.168.1.159:9200] connecting (attempt 1)
[RaatServer localhost @ 192.168.1.159:9200] connected
[RaatServer localhost @ 192.168.1.159:9200] lost client connection. Retrying(0)

Each one churns output state, which pushes a change notification out to every connected Remote, your library mutation rate goes from 16–18 per three-minute window at idle to over 23,000 during these episodes.

The server also logged the update stream overrunning what a client can buffer, three separate times:

[remoting/remotingprotocolv2/historybuffer] crossed the max history buffer size
while disconnected. It's now impossible for anyone to resume, so killing the
logical connection

So there are two things here. The reconnect loop with no backoff is a bug on our side, and we’re filing it. Separately, the macOS Remote clearly isn’t reclaiming memory when it’s fed updates at that rate, that’s the part that actually took your machine down, and we’re filing that too.

What would help us:

Each burst begins within a couple of minutes of the Roon app coming to the foreground on the iPad or iPhone, and ends when that app disconnects. Could you check whether:

  1. Those apps were open during the growth window on 20 September, and
  2. Quitting them fully stops the Remote’s memory from climbing?

If that holds, force-quitting Roon on the iPad and iPhone when you’re not using them should keep your Mac stable while we escalate to development. The RAATServer logs from the iPad or iPhone would also help us understand why they’re resetting the connection.

3

Hi Benjamin,

Thank you for looking into this so quickly, and for the detailed explanation.

I haven’t used Roon on either the iPhone or the iPad for a while, so neither app was open during the window on 20 September. They may have been running in the background, but I hadn’t brought either of them to the foreground.

I’m happy to grab the RAATServer logs from both devices. Could you let me know how to get them from the iOS app?

Once I’ve sent those over, I plan to remove Roon from the iPad and iPhone and leave the Mac Remote running for a while to see whether the memory growth reoccurs or not.

4

Hey @discomoo,

Thanks for checking that detail and for offering to send the RAATServer logs.

We’ve enabled diagnostics on your iPhone, so please bring it online and let us know and then we’ll check for logs on our side. There’s also a way to save logs manually in iOS by going to Settings > Apps > Roon and using the Save Logs option.

Let us know once the iPhone is back online or if you manage to get the manual logs, you can upload them here and let us know:

https://workdrive.zohoexternal.com/collection/nocvrfc5b2ddab55140af8640f1d7ce13291e/external

5

Hi noris,

I’ve uploaded both the iPhone and iPad logs. Had a quick look myself and couldn’t see anything around those days - in fact, the apps haven’t seen much use at all the last couple of months.

Hope this helps narrow down what could be causing the issue

Thanks for the continued support

6

Hello

We have been through the iPhone and iPad logs along with a fresh pull of the server logs covering the past week. The iOS devices are not where this is coming from, so you can leave them out of the picture.

The Mac is in it twice, which we had not spotted before. Besides running the Remote, it also presents itself to the server as an audio endpoint named Popcorn. That endpoint has been announcing itself on your network every thirty seconds or so while refusing connections: over the past week Roon Server attempted 5,584 connections to it and got through four times. So the RAATServer process inside Roon on that Mac is alive enough to advertise and not alive enough to answer. That is on the same machine that ran out of memory.

Two things we would like from the Mac, and the second is the more important one:

  1. ~/Library/Roon/Logs
  2. ~/Library/RAATServer/Logs

Please zip both folders and upload them to the same link you used for the iOS logs.

Separately, could you tell us what device sits at 192.168.0.48, reported as sissieee? It behaves the same way: 2,745 connection attempts over the week and not one of them succeeded. If it is something you no longer use as a Roon endpoint, removing it in Settings > Audio will take a lot of pointless traffic off your network.

One more thing on the server. It logs a network reachability event roughly once a minute, around the clock, about 1,410 times a day since 14 September. Each one re-authenticates your account, refreshes your streaming tokens and re-runs device discovery. We have seen this on another system recently and it settled after updating to the current release, so please update Roon Server and the Mac Remote to 2.73. You are on 2.71 build 1683.

On the panic itself, the server logs show nothing unusual aimed at your Mac that day. It slept at about 00:08 and woke at 08:35, which matches your account, and there were only four Remote disconnections across the whole of 20 September. Whatever consumed the memory happened on the Mac, which is why we want those two folders.

7

Hey,
Thanks for the latest update. I’ve sent the two log folders from the Mac using the link.

sissieee is a raspberryPi running RoPieee (recently rebranded to Verox) - essentially a Roon Bridge connected to my hifi. I haven’t used it in a while, and in fact it had been switched off for a good few months. I’ve powered it back on now.

Mac and Server should now also be up to date.

8

Hello @discomoo,

Thank you for updating both machines and for sending the Mac logs. We pulled fresh server logs today and have two things to report.

Since the Roon Server update on September 30, the network reachability event that was firing about every minute has stopped completely. Server memory also dropped from roughly 11 GB to under 1 GB and has stayed flat since. That is a correction to our earlier post here, which described the server as steady at about 3 GB: the logs from September 23 onward show it climbing steadily on 2.71. Your RoPieee device (sissieee) is also connecting normally now.

We are going through the Mac logs next. In the meantime, please keep an eye on the Roon Remote memory footprint in Activity Monitor. If it starts climbing again, please let us know roughly when it began so we can match it against the server side.