steamclock
Buddybuild crash report on build #459
Buddybuild detected a crash
iOS/AppDelegate.swift line 13
import UIKit
//import BuddyBuildSDK
@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate { <-- CRASHED
var window: UIWindow?
@objc public var rootVC: RootVC!
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey : Any]? = nil) -> Bool {
View File | View Full Crash Details
The stack trace for this crash reports looks like:
objc_msgSend
-[UIWindow _sendTouchesForEvent:]
-[UIWindow sendEvent:]
-[UIApplication sendEvent:]
__dispatchPreprocessedEventFromEventQueue
__handleEventQueueInternal
__handleHIDEventFetcherDrain
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
__CFRunLoopDoSource0
__CFRunLoopDoSources0
__CFRunLoopRun
CFRunLoopRunSpecific
GSEventRunModal
UIApplicationMain
Something in the touch handling system seems to be accessed after being released causing this crash. I haven't been able to reproduce the issue yet.
I think the most likely culprit is WEPopoverController. There are a few Objc object properties that are declared as assign instead of weak which could potentially result in a crash like this (delegate, containerViewProperties, parentView and WETouchableView.delegate).
It might be worth making those changes speculatively but ideally we'd figure out steps to reproduce this first.
@nbrooke Do you think it's worth making the speculative changes to WEPopoverController? We've only received one crash report for this issue.
I'd vote no. If it was even a moderately common crash (couple instances a week or something), it might be worth making a speculative change on very little info (as long as we thing the change itself isn't risky, which I don't think it would be in this case), but with only a single crash report, I feel like we wouldn't even have any idea if the change fixed anything.
