I’m stuck with repeated production crashes in my SwiftUI app and I can’t make sense of the traces on my own.
The symbolicated reports show the same pattern:
Crash on com.apple.CFNetwork.LoaderQ with EXC_BAD_ACCESS / PAC failure
Always deep in CFNetwork, most often in
URLConnectionLoader::loadWithWhatToDo(NSURLRequest*, _CFCachedURLResponse const*, long, URLConnectionLoader::WhatToDo)
No frames from my code, no sign of AuthManager or tokens.
What I’ve tried:
- Enabled Address Sanitizer,
- Malloc Scribble,
- Guard Malloc,
- Zombies.
- Set CFNETWORK_DIAGNOSTICS=3 and collected Console logs.
- Stress-tested the app (rapid typing, filter switching, background/foreground, poor network with Network Link Conditioner).
Could not reproduce the crash locally.
So far:
Logs show unrelated performance faults (I/O on main thread, CLLocationManager delegate), but no obvious CFNetwork misuse.
My suspicion is a URLSession lifetime or delegate/auth-challenge race, but I can’t confirm because I can’t trigger it.
Since starting this investigation, I also refactored some of my singletons into @State/@ObservedObject dependencies. For example, my app root now wires up AuthManager, BackendService, and AccountManager (where API calls happen using async/await) as @State properties:
@State var authManager: AuthManager
@State var accountManager: AccountManager
@State var backendService: BackendService
init() {
let authManager = AuthManager()
self._authManager = .init(wrappedValue: authManager)
let backendService = BackendService(authManager: authManager)
self._backendService = .init(wrappedValue: backendService)
self._accountManager = .init(wrappedValue: AccountManager(backendService: backendService))
}
I don’t know if this refactor is related to the crash, but I am including it to be complete.
Apologies that I don’t have a minimized sample project — this issue seems app-wide, and all I have are the crash logs.
Request:
Given the crash location (URLConnectionLoader::loadWithWhatToDo), can Apple provide guidance on known scenarios or misuses that can lead to this crash?
Is there a way to get more actionable diagnostics from CFNetwork beyond CFNETWORK_DIAGNOSTICS to pinpoint whether it’s session lifetime, cached response corruption, or auth/redirect?
Can you also confirm whether my dependency setup above could contribute to URLSession or backend lifetime issues?
I can’t reliably reproduce the crash, and without Apple’s insight the stack trace is effectively opaque to me.
Thanks for your time and help. Happy to send multiple symbolicated crash logs at request.
Thanks for any help.
PS. Including 2 of many similar crash logs. Can provide more if needed.
Assuming that your crash reports can be trusted [1], the key failure here is in _dispatch_source_set_runloop_timer_4CF, which definitely rings some bells. Check out my response on this thread.
IMPORTANT That response suggest a potential workaround, and I’d love to hear back from you as to whether that helps or not.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Your crash reports make it clear that you have third-party crash reporter installed (to wit, in your firs crash report, frame 2 of thread 10), and it’s not uncommon for third-party crash reports to mess up the Apple crash reporter. I talk about that issue in great detail in Implementing Your Own Crash Reporter.
However, in this case I think it’s reasonable to trust the crash report because the crash is so familiar.