Skip to content

Instantly share code, notes, and snippets.

@jubishop
Created October 18, 2025 20:39
Show Gist options
  • Select an option

  • Save jubishop/2e1beb746cc4459585a80fce6f4cc0ef to your computer and use it in GitHub Desktop.

Select an option

Save jubishop/2e1beb746cc4459585a80fce6f4cc0ef to your computer and use it in GitHub Desktop.

• - Event 70a4b966 happened on October 18, 2025 at 15:23:19 UTC on one iPhone18,1 running iOS 26.0.1. The crash is an EXC_BREAKPOINT raised inside CF_IS_OBJC on an AVFoundation worker thread while handling an AVTimebaseObserver callback, and it fired immediately after the system posted mediaServicesWereResetNotification (app was still in foreground).

  • During a media-services reset our playback stack runs handleMediaServicesReset() to tear down and rebuild audio state (PodHaven/Play/PlayManager.swift:470). That calls clearOnDeck() → PodAVPlayer.clear() which re-adds the periodic time observer after relaunching the episode (PodHaven/Play/Utility/ PodAVPlayer.swift:226).
  • In that observer we pass DispatchQueue.global(qos: .utility) to AVPlayer.addPeriodicTimeObserver. Apple explicitly documents that supplying a concurrent queue “isn’t supported and results in undefined behavior”; you must provide a serial queue or nil. citeturn6apple-docs-mcp__get_apple_doc_content0 Combined with the media-services restart (which Apple warns requires complete reinitialization of audio objects), this undefined behavior surfaced as the CF_IS_OBJC crash when the timebase callback fired while the old player was being torn down. citeturn5apple-docs-mcp__get_apple_doc_content0
  • The “playState > tableRecord+Insert.swift” text in Sentry’s title does not align with the crashing thread. I found no evidence of a GRDB insert running at the time; the only active code on the crashing stack is AVFoundation’s timebase observer. The DB-related log line is likely a side-effect from other threads.

Recommended next steps:

  1. Change the periodic observer queue to a dedicated serial queue (or nil to use the player’s private queue), then verify the media-services reset flow again. (PodHaven/Play/Utility/PodAVPlayer.swift:229)
  2. Add a stress test or manual QA step that toggles AVAudioSession.mediaServicesWereResetNotification to ensure the player recovers without spawning crashes.
  3. Once the queue fix is in place, consider logging inside handleMediaServicesReset() to confirm reinitialization completes before resuming playback, matching Apple’s guidance. citeturn5apple-docs-mcp__get_apple_doc_content0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment