losnoco
Crashes on startup when file tree has a cloud storage folder loaded that is only partially downloaded [3225]
I use Proton Drive and store music there. I loaded my mixes folder which only has some of the files downloaded. When I start up cog and Proton Drive tries to download a file (I guess because Cog is reading it in the background) then Cog crashes.
If I quit proton drive and then open Cog it runs fine.
Logged an issue with apple and this is the the output from running the app via terminal.
Cog.app/Contents/MacOS
-> ./Cog
objc[48965]: Class RedundantPlaylistDataStore is implemented in both /Applications/Cog.app/Contents/Frameworks/CogAudio.framework/Versions/A/CogAudio (0x100c66e10) and /Applications/Cog.app/Contents/MacOS/Cog (0x1005c9040). One of the two will be used. Which one is undefined.
objc[48965]: Class SHA256Digest is implemented in both /Applications/Cog.app/Contents/Frameworks/CogAudio.framework/Versions/A/CogAudio (0x100c670e0) and /Applications/Cog.app/Contents/MacOS/Cog (0x1005c9270). One of the two will be used. Which one is undefined.
CoreData: fault: One or more models in this application are using transformable properties with transformer names that are either unset, or set to NSKeyedUnarchiveFromDataTransformerName. Please switch to using "NSSecureUnarchiveFromData" or a subclass of NSSecureUnarchiveFromDataTransformer instead. At some point, Core Data will default to using "NSSecureUnarchiveFromData" when nil is specified, and transformable properties containing classes that do not support NSSecureCoding will become unreadable.
CoreData: warning: Property 'metadataBlob' on Entity 'PlaylistEntry' is using nil or an insecure NSValueTransformer. Please switch to using "NSSecureUnarchiveFromData" or a subclass of NSSecureUnarchiveFromDataTransformer instead.
2025-09-08 21:42:27.127 Cog[48965:374532] It's not legal to call -layoutSubtreeIfNeeded on a view which is already being laid out. If you are implementing the view's -layout method, you can call -[super layout] instead. Break on void _NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future.
[1] 48965 terminated ./Cog
Actually the bug is not specific to the update so have updated the title and description.
I can't replicate with freshly uploaded files. How do I replicate this?
Edit: What formats do you have uploaded? I uploaded a 344MB WavPack file, then forced it Online Only. When Cog started, it forced Proton Drive to download the file, which made Cog hang for the duration of the download. No crash.
Edit 2: Added a whole album of files to the drive. Forced everything online-only. Started Cog. It waited patiently for all the files to download as it accessed them.
Hi thanks for looking into this. I have about 68 files in a folder 50% are online-only. Extensions are .mp3, .opus, .m4a.
File contents example:
If Proton Drive is not running the folder loads correctly.
If it is running that is when you get the crash on startup or if you select the folder in the file tree.
I do notice that when I opened cog with proton drive running that proton starts downloading one of the mixes maybe it got cached in cog somehow? Since it's about 200MB maybe because it's in a "downloading" state that is what causes the crash?
I checked Cog on a mix of files, when Cog asks to access a file, it hangs in the open function until the download completes.
Quick question, is this an Intel machine, or an Apple Silicon machine? I can't actually debug crashes on Intel machines, because my newest Intel machine is too old to run recent Xcode or macOS versions.
Hmm. The only other option I have is that stable OS versions have the bug but bleeding edge does not.
I suppose I could put several thousand small files in my drive and let it see those.
Did you add the share folder directly as the root of the file tree, or did you add a subdirectory of it?
I tend to wait a long time before updating my OS so currently I am on Sonoma 14.7.8 (23H730) if that helps. When Tahoe comes out I'll update to Sequoia and maybe that will fix the issue?
I think I have done it both ways but when I recreated the bug I added the share folder as the root of the file tree. The shared drive and that specific shared folder all have a mix of online and offline files
The funny thing is, I haven't seen any crashes recently from macOS 14. Neither Sentry nor Apple, if you crashed the App Store version.
The funny thing is, I haven't seen any crashes recently from macOS 14. Neither Sentry nor Apple, if you crashed the App Store version.
I have installed via homebrew.
The funny thing is, I haven't seen any crashes recently from macOS 14. Neither Sentry nor Apple, if you crashed the App Store version.
I have installed via homebrew.
Which means you're using the Sparkle self-updating version. It still reports crash logs to Sentry, if you enabled that. If enabled, it will prompt to send a crash log on the next launch.
If I don't see a crasher from you, please consider trying the App Store version temporarily, unless you don't have an Apple ID to use the Store. It's a free listing, well, free to download. I can't complain that it costs me money to list it there, since I am still using the notarized signatures on my non-Store version as well.
The Store version will also report crashes to me through Apple, and will send them from the OS, so they don't depend on the app being able to send the crash dumps without just crashing itself again before it can send them.
If you still want to try the Sentry crash reporter again, in case you turned it off:
defaults read org.cogx.cog sentryConsented
This should be reset to 1 if you want to enable it outside of the dialogs in the app, in case you can't get it to run long enough to report the crash.
Just in case:
- Crash the app with the crash bug, either App Store or Sparkle version
- Do not restart the app yet!
- Shut off your file share that causes the crash
- Now restart the app
- Report the crash, preferably with a comment about the crash so I can identify it. Name and email are entirely optional, fill them out with a contact point if you prefer me to email you responses. You can even just fill out only the name with what you use here, again, so I can identify the crash report.
Note that the Sentry crash report system is a different dialog from the system crash dialog, and pops up on a successful re-launch of the app. Any system crash dialog type crashes logged by the app will not be sent to me unless you're running the App Store version, or unless you round up the crash report from your system and send it to me somehow.
Hi I installed the App Store version and reported the crash: Incident ID: D68A8310-4845-490B-A2DD-DA78D7B53AB5
I could not recreate the crash from hitting play on a non-offline file in COG but it definitely frozen while it was waiting for the file to download. I hope this is helpful, it is a bit tricky to recreate🙏
Yes, it's supposed to freeze the main thread as it is waiting for the file to open. I could try to run the message loop while waiting, but it would be painful, especially if the user does something to interrupt the opening, or tries to open a different file.
I'll check out that crash, though.