JavaScriptCore WebKit EXC_BAD_ACCESS stürzt nach dem Ausführen des Rückrufs mit Daten aus dem Hintergrundthread ab

8

Ich versuche gerade, Abstürze in einer JavascriptCore-Implementierung einer Schnittstelle für nativen Code zu beheben, um einige Arbeiten im Namen des JavaScript-Codes in der WebView durchzuführen.

Der Absturz tritt manchmal sehr bald nach dem Start der Anwendung auf. In anderen Fällen kann es einige Minuten dauern, bis Hunderte von Aufrufen an den systemeigenen Code ausgeführt werden.

Dies sind die obersten zwei Zeilen für das Backtrace eines jeden Crashs:

%Vor%

Hier ist eine vereinfachte Version meines View-Controllers:

%Vor%

Das JSExport-Protokoll selbst und die Implementierung des ausführenden Codes. Zum Testen habe ich die eigentliche Arbeit entfernt und nur ein Wörterbuch mit Dummy-Daten zurückgegeben, und der Absturz tritt immer noch auf.

%Vor%

Die Methoden executeBackground und executeCallback sind Hilfsfunktionen, und executeCallback verwendet setTimeout als Antwort auf das, was ich in dieser SO-Post / Antwort gelesen habe: und es scheint, andere Abstürze im Zusammenhang damit gelöst zu haben zu sperren.

Wenn ich executeBackground für die folgende Funktion austausche, die nur im Hauptthread läuft, konnte ich den Absturz nicht replizieren:

%Vor%

Es scheint, dass es ein Problem gibt, das auftritt, wenn Daten, die in einem Hintergrund-Thread erstellt wurden, an das WebView übergeben werden, aber nach dem Durchlaufen der Dokumentation bin ich unsicher, was das sein könnte. Das einzige Tabu, das ich erwähnte, war die Weitergabe von Daten zwischen mehreren JSVirtualMachine-Instanzen. Dies scheint nicht anwendbar zu sein, da ich nur mit einer einzelnen WebView-Instanz interagiere. Jede Hilfe bei der Ermittlung wird sehr geschätzt!

Aktualisieren

Ich habe das Problem gelöst, indem ich die Verwendung von Grand Central Dispatch direkt für NSOperationQueues ausgeschaltet habe. Nach dem Ändern von executeBackground zu den folgenden, sind die Abstürze nicht wieder aufgetreten.

%Vor%

Obwohl ich nicht wirklich beweisen beweisen kann, dass dies den Absturz behoben hat, haben wir diese Funktionalität ziemlich ausführlich getestet und haben sie nicht mehr gesehen. Der Grund, warum ich dies nicht als Antwort auf meine eigene Frage gepostet habe, ist, dass ich nicht weiß, warum genau das anders und / oder besser ist. Wenn jemand einen Einblick hat, was die Änderung zu NSOperationQueues möglicherweise gelöst hat, würde es sehr geschätzt werden!

    
Aaron 15.07.2016, 16:32
quelle

0 Antworten