Open aaronbarsky opened 3 weeks ago
Hi @aaronbarsky - you mentioned this being consistent; do you know the conditions or sequence of events that leads to the crash. Being able to have a reproduction case would be immensely helpful to resolving this.
By consistent, I mean that the call stack is exactly the same in each case. It happens about 1/500 sessions.
The challenge is that the start of the crash is
CoreFoundation _inputStreamCallbackFunc
which makes it quite tough to write a unit test or minimally reproducible example.
Summary
Crashlytics is reporting a very rare but consistent crash on the com.apollograph.websocket queue.
The app is a mix of 60% foreground and 40% background.
Version
1.9.2
Steps to reproduce the behavior
Unfortunately I only have crash logs
Logs
No response
Anything else?
My hunch is that it's the FoundationStream teardown sequence:
stream.delegate is an
unowned(unsafe)
var.There are several codepaths where cleanup is not called on com.apollographql.websocket. When this happens, delegate can be set to nil as the CFReadStream is attempting to invoke a callback on the deallocated delegate.