Crashlytics Bericht von Ausnahme in Framework

Question

Ich habe eine App und zwei App-Erweiterungen (Tastatur und iMessage-Erweiterungen), die drei Frameworks verwenden, die wir gebaut haben. Die Frameworks sind Teil des Projekts und haben jeweils ihr eigenes Ziel. Die App und die Erweiterungen werden in diesen Frameworks verknüpft und wir verwenden sie, um allgemeine Aufgaben wie den Zugriff auf eine Datenbank auszuführen.

Wenn wir Crashlytics im AppDelegate initialisiert wie diese

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey : Any]? = nil) -> Bool 
{ 
    Fabric.with([Crashlytics.self]) 

    ... more 
} 

Dann sollte es stürzt sogar berichten, wenn der Absturz in einem der verknüpften Rahmen aufgetreten ist, nicht wahr? Wenn die dSYM-Dateien für die App, die App-Erweiterungen und die Frameworks vorhanden sind, dann sollte es möglich sein, den Absturz sogar in den Framework-Code zu symbolisieren, richtig?

Ich habe einige Schwierigkeiten, Crystigytics zu bekommen, um Dinge zuverlässig zu melden. Wenn ich Crashlytics.sharedinstance().crash() in eine Funktion im Hauptleitungscode einfüge, dann scheint es, dass es gut funktioniert. Aber wenn ich eine Funktion von einem UIAlertAction wie folgt aufrufen ...

@objc func onPreviewLongPress(_ notification : Notification) 
{ 
    if let userInfo = notification.userInfo, let collectionName = userInfo["collectionName"] as! String? { 
     let alert = UIAlertController(title: "", message: "Enter the code:", preferredStyle: .alert) 
     alert.addTextField { (textField) in 
      textField.text = "" 
     } 
     alert.addAction(UIAlertAction(title: "Cancel", style: .default, handler: nil)) 
     alert.addAction(UIAlertAction(title: "OK", style: .default, handler: { (_) in 
      let textField = alert.textFields![0] 
      // original code snipped 
      if textField.text!.doesContain("crash") { 
       self.callForCrash() 
      } 
     })) 
     self.present(alert, animated: true, completion: nil) 
    } 
} 

private func callForCrash() { 
    Crashlytics.sharedInstance().crash() // DOES NOT REPORT!!! 
} 

Ich habe auch versucht, einen Absturz zu zwingen durch Teilung zwingt durch Null ...

private func callForCrash() { 
    let nom = 12; 
    let result = nom/zeroNum(13) 
    print(result) 
} 
// separate function to allow division by zero to get through swift parsing 
private func zeroNum(_ num: Int) -> Int { 
    return num - num; 
} 

Dieses berichten auch nicht. Wenn ich aber gerade die Crashlytics.sharedInstance().crash() in den Code vor dem Alert setze, dann wird es gut berichtet.

Ich habe den Installationsvorgang und den Beispielcode in den letzten paar Tagen mehrmals durchgeführt.

• Die Konsole zeigt die Version, die ich zu Test bin versucht, einschließlich der brandneuen Build-Nummer
• Die Konsole ist nicht Probleme mit fehlenden DSYM Dateien berichten,
• ich habe nicht Bitcode aktiviert,
• Ich baue nur 'aktive Architektur' = Ja (Ich habe auch versucht, das auf Nein zu setzen),
• Das Skript läuft für die App und die zwei App-Erweiterungen (Ich habe noch nicht versucht, eine Erweiterung zu testen)
• Ich habe versucht, von Xc zu laufen ode dann stoppen, um nach der Installation zu starten,
• Ich habe auch versucht, Ad-hoc-Build und die Installation über das Geräte-Fenster (Xcode 9.2)
• Ich trigger den Absturz und starten Sie dann die App neu, so wird es berichten

Kann jemand sehen, was ich verpasst haben könnte? Ich habe gelesen, dass arm64 ein Problem ist, aber das war ziemlich alt, also bin ich mir nicht sicher, ob das immer noch ein Problem ist. Kann ich im Protokoll nach etwas suchen, das mir sagt, ob es funktioniert oder nicht? UPDATE Ist es möglich, dass sowohl die Android- als auch die iOS-Version der App mit der gleichen ID "com.mydomain.myapp" zu unvorhersehbarem Verhalten führen kann? Es wird separat auf der Fabric-Konsole angezeigt.

TIA, Mike

Answer 1

Ich werde weitermachen und schreibe dies als eine Antwort, weil es abstürzt scheint zu berichten, die in dem Rahmen geschehen, der der primäre Punkt war.Es ist nur eine teilweise Antwort, weil ich auch über die App-Erweiterung gesprochen habe. Ich habe Berichte von der Tastaturerweiterung erhalten, aber bisher nichts von der iMessage-Erweiterung.

Wie auch immer, es scheint mit Frameworks zu arbeiten. Ich nahm eines der Gerüste wir diese Funktionen eingebaut und das hinzugefügt:

public static func doCrash() { 
    func1() 
} 

private static func func1() { 
    func2() 
} 

private static func func2() { 
    let _ = 10/prepNum(5) 
} 

private static func prepNum(_ int:Int) -> Int { 
    return int - int 
} 

Wenn die Division durch Null die App getroffen wird abgestürzt und, nachdem ich es neu gestartet, bekam ich den Crash-Bericht mit dem folgenden:

libswiftCore.dylib 
specialized _fatalErrorMessage(_:_:file:line:flags:) + 124 
1 CommonKit _T012CommonKit9LocalFileC5func233_BC978A475DDB24483E4F12A335D91E70LLyyFZ + 136 
2 CommonKit _T012CommonKit9LocalFileC5func133_BC978A475DDB24483E4F12A335D91E70LLyyFZ + 20 
3 CommonKit _T012CommonKit9LocalFileC7doCrashyyFZ + 20 
4 MyApp StickerViewController.swift line 369 
    StickerViewController.callFrameworkForCrash() ->() 

Es scheint also nicht in der Lage zu sein, den Absturz vollständig in das Framework zu symbolisieren. Aber wenn wir uns die Ergebnisse _T012 CommonKit Lokale C7 doCrash yyFZ wir den Namen der Funktion herausziehen können, die CommonKit abgestürzt :: LocalFile.doCrash().

Ich hoffe, dass dies für jemanden in der Zukunft hilft. Ich werde versuchen, etwas davon in der iMessage-Erweiterung zu bekommen.

Mike