iOS5 stürzt ab, während der runMode:beforeDate:
Ich habe ein problem mit der Kompatibilität meiner Anwendungen mit iOS 5 b7 und GM-Versionen.
Tritt das Problem in den nächsten Zeilen des Codes:
do {
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
} while (!done);
Stürzt die App mit der signal EXC_BAD_ACCESS
nach einigen Iterationen.
Die Anzahl der Iterationen übergeben werden, ist zufällig (von 2 bis 7).
Auch alles Recht gut funktioniert, auf iOS4 und iOS3.
Dasselbe Problem tritt auf in apples Beispiel: XMLPerformance Probe.
Was haltet Ihr von diesem?
12. Oktober Tausende von Nutzern meiner app ein upgrade auf iOS5 und ich will nicht, dass meine app zu sein, mit solch einem seltsamen Fehler im AppStore.
Du musst angemeldet sein, um einen Kommentar abzugeben.
4 Stunden vergangen und ich habe das problem gefunden. Ich werde beschreiben, wie ich das problem gelöst in
XMLPerformance sample
.War das problem in
NSAutoreleasePool
. Es ist@property (nonatomic, assign) NSAutoreleasePool *downloadAndParsePool;
. Wenn Sie die app beginnt zu ladenTop300 Paid Apps RSS
neuer thread erstellt wird mit[NSThread detachNewThreadSelector:@selector(downloadAndParse:) toTarget:self withObject:url];
. Also in diesem thread, die sollten wir uns halten lokale autorelease pool. Es geschieht in der folgenden Weise:So, in
downloadAndParse:
sieht alles gut aus. Schauen wir uns nun in einer Methode, die aufgerufen wird, wenn ein Element aus dem RSS-parsing:Wie Sie sehen dort Zeilen :
So genau, dass die Linien, die die Ausnahme verursacht. Wenn ich das kommentieren klappt alles Super.
Aber ich habe beschlossen, nicht nur kommentieren, dass Linien, sondern ersetzen auch
NSAutoreleasePool
im- (void)downloadAndParse:(NSURL *)url
mit@autorelease
block, denn es wird gesagt, dass es effizienter ist:Nun funktioniert alles wunderbar. Das einzige problem, das ich noch nicht gelöst ist:
Also wenn jemand irgendwelche Gedanken zu diesem problem posten kann, ein anderer eine Antwort und vielleicht versuchen zu erklären, mehr richtig den bug-fix. Ich werde froh sein, zu akzeptieren, dass Antwort.
Dank.
Dieser sieht aus wie Speicher problem, überprüfen Sie bitte, Apple Technote QA1367 "Finden EXC_BAD_ACCESS Wanzen in Kakao-Projekt"
In Ihrem code, versuchen Sie diese zu crash so bald wie möglich:
Löst es nicht das problem, nur macht der crash früher erfolgen, und hoffentlich geben Sie eine aussagekräftige callstack zu studieren.
Wenn Sie multi-threading, gut... Sie könnten versuchen, zu drucken, "aktuellen" thread-id in die Konsole, um zu überprüfen, dass wirklich alles im thread, wo Sie erwarten, dass Sie ausgeführt werden. Vor allem, stellen Sie sicher, dass alle UI-Zeug ist im Haupt-thread, auch wenn dieser code ausgeführt wird, die als Nebeneffekt von anderen code (Fehler-popups, vielleicht).
Führen Sie Ihre app mit Instrumente, stellen Sie sicher, dass Speicher-überprüfung zu passieren, alle 1 oder 2 Sekunden. Langsam, aber doch wieder Sie wollen informiert werden, möglichst nahe an der tatsächlichen Speicher-problem wie möglich.
Suchen Sie in Ihren code ein: Woher, dass "fertig" variable kommen, und die änderungen es Wert und wenn? Jetzt sieht es ziemlich magisch.
Auch Sie könnte prüfen, die Rückgabewert runMode:beforeDate um sicherzustellen, dass es ausgeführt wurde. Wenn der return-Wert ist NEIN, runLoop war gar nicht laufen. Vielleicht sind einige andere Teile des Codes nicht in den Griff solchen Fall?
done
variable ist alles ok. runMode:beforeDate funktioniert. Ich habe das problem gefunden und wird bald Antworten. Überprüfen Sie es, es gibt auch einige Fragen.Nur mein kleiner Beitrag.
So, ich habe das gleiche problem, ich habe zu entdecken, die in iOS5, die Sie nicht brauchen, um Ihr eigenes NSAutoreleasePool in einem thread (von performSelectorOnMainThread).
Dann in Ihrem code (eine xml-parser - so wie mir), ich denke, Sie haben, um eigenen code von iOS4 und iOS5.
Mit iOS4, müssen Sie NSAutoreleasePool, aber nicht mit iOS5.