Unreproducible webcore stürzt ab

Habe ich eine iPad app, die im App-Store für etwa drei Monate jetzt, und ich habe Empfang einige seltsame crash-Berichte, die ich nicht herausfinden können. Diese sind nicht so Häufig, hab um die 15-20 Instanzen seit dem Start, aber immer noch Häufig genug, um wirklich bug mich. Die Abstürze sind etwas anders (siehe stack-traces unten), aber da Sie im Zusammenhang mit WebCore ich vermute, Sie haben zu tun mit der Verwendung der UIWebView in der app und haben möglicherweise eine gemeinsame Ursache, obwohl ich bin nicht 100% positiv. Die Bereitstellung Ziel der app ist iOS 6.0, aber stürzt ab, erscheinen auf dem iPad 2, iPad 3 und iPad Mini, die ausschließlich auf iOS 7.

Gibt es nur einen Platz in der app, wo ich mit einem webview, die für die Anzeige von news-Artikel web-Seiten aus verschiedenen Quellen. Ich habe einen view-controller, der hat ein UIWebView als seine Ansicht. Es ist eine Instanz der view-controller, dass das Leben überall in der app, jedes mal, wenn ein neuer Artikel ausgewählt wird, wird die bestehende webview neu geladen, mit der url des neu gewählten Artikels.

Einer der vorgeschlagenen Lösungen auf der Basis der Diskussion rund um WebCore Themen vorgeschlagen, die Einstellung des webviews delegate Eigenschaft nil im controller dealloc Methode. Leider glaube ich nicht, es ist anwendbar in meinem Fall, weil die view-controller nicht freigegeben ist, während der gesamten Lebensdauer der app.

Ein weiteres Problem könnte sein, falsche Webseiten, haben schlechte Bild-Referenzen in der CSS (loadPendingImages Absturz). Ich konnte nicht finden, eine solche Seite allerdings noch nicht.

Auch habe ich überprüft und sicher gestellt, dass zu tun webview-bezogene Operationen auf dem Haupt-thread.

Abstürze

Exception Type: EXC_BAD_ACCESS 
Code: KERN_INVALID_ADDRESS

mit den folgenden stack-traces (volle hier)

0 WebCore WebCore::StyleResolver::applyMatchedProperties(WebCore::StyleResolver::MatchResult const&, WebCore::Element const*) + 815
1 WebCore WebCore::StyleResolver::applyMatchedProperties(WebCore::StyleResolver::MatchResult const&, WebCore::Element const*) + 788
2 WebCore WebCore::StyleResolver::styleForElement(WebCore::Element*, WebCore::RenderStyle*, WebCore::StyleSharingBehavior, WebCore::RuleMatchingBehavior, WebCore::RenderRegion*) + 948
3 WebCore WebCore::Document::styleForElementIgnoringPendingStylesheets(WebCore::Element*) + 96
4 WebCore WebCore::Element::computedStyle(WebCore::PseudoId) + 142
5 WebCore WebCore::ComputedStyleExtractor::propertyValue(WebCore::CSSPropertyID, WebCore::EUpdateLayout) const + 458

und

0 WebCore WebCore::StyleResolver::loadPendingImages() + 1153
1 WebCore WebCore::ResourceRequestBase::~ResourceRequestBase() + 104
2 WebCore WebCore::StyleResolver::applyMatchedProperties(WebCore::StyleResolver::MatchResult const&, WebCore::Element const*) + 782
3 WebCore WebCore::StyleResolver::styleForElement(WebCore::Element*, WebCore::RenderStyle*, WebCore::StyleSharingBehavior, WebCore::RuleMatchingBehavior, WebCore::RenderRegion*) + 948
4 WebCore WebCore::Document::styleForElementIgnoringPendingStylesheets(WebCore::Element*) + 96
5 WebCore WebCore::Element::computedStyle(WebCore::PseudoId) + 142

und

0 WebCore WebCore::StyleResolver::adjustRenderStyle(WebCore::RenderStyle*, WebCore::RenderStyle*, WebCore::Element*) + 19
1 WebCore WebCore::StyleResolver::styleForElement(WebCore::Element*, WebCore::RenderStyle*, WebCore::StyleSharingBehavior, WebCore::RuleMatchingBehavior, WebCore::RenderRegion*) + 964
2 WebCore WebCore::Document::styleForElementIgnoringPendingStylesheets(WebCore::Element*) + 96
3 WebCore WebCore::Element::computedStyle(WebCore::PseudoId) + 142
4 WebCore WebCore::ComputedStyleExtractor::propertyValue(WebCore::CSSPropertyID, WebCore::EUpdateLayout) const + 458
5 WebCore WebCore::CSSComputedStyleDeclaration::getPropertyValue(WebCore::CSSPropertyID) const + 42

und

0 WebCore WebCore::TimerBase::heapDeleteMin() + 37
1 WebCore WebCore::ThreadTimers::sharedTimerFiredInternal() + 94
2 WebCore WebCore::ThreadTimers::sharedTimerFiredInternal() + 94
3 WebCore WebCore::timerFired(__CFRunLoopTimer*, void*) + 24
4 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14
5 CoreFoundation __CFRunLoopDoTimer + 782

Hat jemand ähnliches erlebt abstürzt? Wenn dem so ist:

1. Gibt es Möglichkeiten, zu replizieren?

2. Wie kann man Debuggen, ohne diese replizieren?

3. Was behebt die Probleme gelöst?

Dank!

iOS 7 verfügt über mehrere große Probleme mit der Grafik-rendering. Das Problem, das Sie versuchen, die Spur ist wahrscheinlich und OS-Ebene (oder SDK-level) - Problem. Zu Wagen, ein Blinder denke, es gibt einige CSS-Transformationen und-Animationen, die den Absturz verursachen. Ihre einzige Hoffnung zu isolieren, die Ursache zu finden ist die Seite, die Sie verursacht, und selbst dann Sie wahrscheinlich werden nicht in der Lage, etwas dagegen zu tun.
Ja, leider habe ich nicht bekommen, zu replizieren es selbst noch nicht und da bin ich auf das laden von news-Artikel aus verschiedenen (30+) news-Quellen habe ich das Gefühl, dass ich nicht in der Lage sein, es zu tun zu jeder Zeit bald. Falls sonst niemand eine bessere Idee, was wäre hier Los, wir müssen warten, bis iOS 7.1 und sehen, wenn Sie eine dieser Fragen.
Ich habe das replizieren dieser Fehler in cordova ios7 mit Fenster.requestAnimationFrame in eine Rekursion Schleife zu Schritt animieren sprite emoticons. Scheint, dass es passiert, wenn die app erwacht aus einem langen Schlaf und versucht, Sie zu animieren, wieder.
7.1 nicht beheben diese Probleme, leider. Nicht in beta2, mindestens.

InformationsquelleAutor Botond Székely | 2013-11-08

5

Ich hatte genau das gleiche Problem in einer app mit der ich gearbeitet habe, ist es komischerweise trat nur auf älteren Geräten mit iOS 7. Ich vermute, das hat etwas zu tun mit dem Sie nicht in der Lage, Schritt zu halten.

Was ich hatte, war ein UITableView wo einer der Reihen würde einen UIViewController hatte, die UIWebView auf es für benutzerdefinierte Werbung. Was ich gefunden habe ist, dass auf die älteren Geräte, Objekte und Speicher frei sein würde bis weit öfter als ich gesehen hatte, in anderen Plattformen. Ich könnte imitieren die crash sehr leicht auf einem iPhone 4 geht in /out auf dem Bildschirm 2 oder 3 mal. Wo, wie ein iPhone 5 ich verbrachte 15 Minuten das gleiche zu tun und konnte nicht die Schuld it.

Ich weiß, Sie fühlen können, wie Sie Ihre controller nicht dealloc würde, aber es klingt wirklich, als ob es ist oder einige Referenz wird gelöscht, ich habe auch gesehen, meine Stellvertretung Referenzen verschwinden ein paar mal in diese app.

Mein Rat und was für mich gearbeitet ist, um die Ausführung zu stoppen der webview und alles, was zu nil wenn Sie können.

In einem Fall auf meine app, die ich wählte, es zu tun auf der viewWillDisappear Rückruf, weil in meinem Fall gegangen war, die vom Benutzer neu erstellt und später, so habe ich ausgeblendet, alles, was etwa so:
```
[webView stopLoading];

self.webView.delegate = nil;
self.webView = nil;
```
- Danke für den Tipp, Simon. Ich werde versuchen, diese. Leider, da kann ich nicht replizieren, das Problem, das ich nicht in der Lage sein zu wissen, ob diese funktioniert oder nicht, zumindest bis ich release ein update für meine app.
- hoffentlich hilft es Ihnen, eine schnelle Möglichkeit wäre, das zu tun, was ich Tat, und sendet eine Nachricht an alle Ihre Freunde und Sie bitten, zu borgen, ein älteres Gerät für ein paar Tage. Ich finde das iPhone 4 Griff, iOS 7 sehr schlecht
- Eine Notiz von Vorsicht, wer nur nimmt, der code oben ist. Können Sie Ihnen Fehler, wenn Sie die Bildschirme der Benutzer kann sich zu von dem Bildschirm, der hat die webview. Zum Beispiel, stellen Sie sich vor, Sie haben eine navigation-bar-Taste drückt, dass ein weiterer Bildschirm auf dem navigation-controller. Es rufen viewWillDisappear und klar aus self.webView.delegate und self.webView. Dann, wenn Sie wieder kommen, um die webview-Bildschirm werden Sie noch sehen die webview, aber jeder code, der darauf verweist self.webView nichts.
- sehr wahr, gut nennen
InformationsquelleAutor Simon McLoughlin
1

Blick auf Ihre Javascript-to-Objective-C-code-und wenn Sie ausführen/aufrufen von javascript-code, stellen Sie sicher, dass Skript nicht aufrufen neue Anrufe zu Objective-C.

Dies ist die ordnungsgemäße Verwendung:
```
Javascript >> Objective-C

Objective-C >> Javascript
```
Dies ist Grund für den Absturz:

Objective-C >> Javascript >> Objective-C (hier ist möglich, Absturz abhängig von einigen race conditions)

Lösung speziell für Ihre Projekt-code. Aber am einfachsten wäre, wickeln Sie alle Javascript in setTimeout() um die Ausführung des Zeitplans im Javascript-thread. Hier ist ein einfaches Beispiel, Ihre Objective-C-code ausführen, muss dieses Skript:
```
storeUserPhoneNumber("011 123 4567");
```
Crash passieren wird, wenn storeUserPhoneNumber - Funktionsaufrufe zurück, die Objective-C-code (direkt oder indirekt) in seinem Körper. Um dies zu beheben einfach wrap-code in setTimeout so:
```
setTimeout(function() {
    storeUserPhoneNumber("011 123 4567");
}, 0);
```
Was dies erreicht ist, zu analysieren Javascript-code aus string und legen Sie es in Funktion ist geplant umgesetzt werden später auf die nächste Veranstaltung-loop-tick-releasing-Kontrolle zurück zu Objective-C nach dem Parsen JS-code.

Denken Sie daran, Sie müssen dieses Update auf allen Objective-C >> Javascript anrufen 😉
- Wenn Sie Recht haben, deine Antwort ist sehr interessant. Haben Sie irgendwelche Unterlagen/Referenzen/Beispielprojekte sichern Sie Ihre Ansprüche ? Warum sollte "Objective-C >> Javascript >> Objective-C" Absturz"? Und was ist mit javascript ausgeführt von Objective-C nicht ausgeführt, auf den javascript-thread ? Es scheint seltsam, dass dies würde nicht dokumentiert werden.
- Es ist leicht reproduzierbar mit einfachen test-Projekt, wenn Sie möchten, verbringen einige Zeit, um zu bestätigen, die für Ihre self. Ich denke, dass das ein bug in der IOS-Umsetzung-und nicht eine Funktion, die dokumentiert werden.
InformationsquelleAutor Alex

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.