Runaway memory usage since Sonoma and/or latest Cog update #379

Closed
opened 2023-10-11 09:38:36 -03:00 by bhilimon · 4 comments
bhilimon commented 2023-10-11 09:38:36 -03:00 (Migrated from github.com)

I've been running Sonoma for about 1.5 weeks now and also upgraded to the latest Cog from the app store at that time (2846). Since then, Cog just endlessly uses more and more memory until my system completely crashes (Mac Mini M2). It was at 48g of memory/swap this morning and already back to 3+ gig in about 2 hours this morning. I play .mp3 files exclusively over a network share. Let me know if there is anything I can do help figure this out.

I've been running Sonoma for about 1.5 weeks now and also upgraded to the latest Cog from the app store at that time (2846). Since then, Cog just endlessly uses more and more memory until my system completely crashes (Mac Mini M2). It was at 48g of memory/swap this morning and already back to 3+ gig in about 2 hours this morning. I play .mp3 files exclusively over a network share. Let me know if there is anything I can do help figure this out.
bhilimon commented 2023-10-11 09:40:38 -03:00 (Migrated from github.com)

Actually, I see the Cog upgrade is newer than the Sonoma install. It's possible it started with the latest Cog and not Sonoma.

Actually, I see the Cog upgrade is newer than the Sonoma install. It's possible it started with the latest Cog and not Sonoma.
bhilimon commented 2023-10-11 11:38:11 -03:00 (Migrated from github.com)

Little more messing around, it looks like just pausing a song for a second releases all of the memory, back down to a couple hundred meg. It does start climbing again though.

Little more messing around, it looks like just pausing a song for a second releases all of the memory, back down to a couple hundred meg. It does start climbing again though.
ElbowBaggins commented 2023-10-11 11:59:42 -03:00 (Migrated from github.com)

I see this exact behaviour on the current latest stable Cog from the website, on Sonoma. Mac Studio M1 Max.

Pausing or changing tracks immediately frees the memory but usage climbs fairly linearly and constantly during playback. This doesn't always happen, sometimes memory usage stays nominal during playback. However, when it doesn't, the describe effect occurs. I am not sure what causes it, I have observed this behaviour in multiple formats. NSF was the worst offender in my examination, but this correlation may be spurious.

I see this exact behaviour on the current latest stable Cog from the website, on Sonoma. Mac Studio M1 Max. Pausing or changing tracks immediately frees the memory but usage climbs fairly linearly and constantly during playback. This doesn't _always_ happen, sometimes memory usage stays nominal during playback. However, when it _doesn't_, the describe effect occurs. I am not sure what causes it, I have observed this behaviour in multiple formats. NSF was the worst offender in my examination, but this correlation may be spurious.
kode54 commented 2023-10-11 21:12:15 -03:00 (Migrated from github.com)

I'll be looking at this and the SID crashing issue tonight and possibly also tomorrow if it takes me too long to fix them.

This one looks like it might be because I'm not using adequate @autoreleasepool blocks in the Converter thread, which I moved more work back to again. I forget if I had enough autoreleasepools there at all, or if I removed them after I simplified the converter.

I'll be looking at this and the SID crashing issue tonight and possibly also tomorrow if it takes me too long to fix them. This one looks like it might be because I'm not using adequate `@autoreleasepool` blocks in the Converter thread, which I moved more work back to again. I forget if I had enough autoreleasepools there at all, or if I removed them after I simplified the converter.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: chris/Cog#379
No description provided.