Meine App stürzt ab und wird geschlossen, und es gibt sehr wenig Informationen darüber, warum

Question

Ich habe einen Absturz und würde mich sehr über einige Ratschläge freuen, wie Sie das Problem finden und beheben können. Das Spiel schaltet sich einfach ab. Wenn die App angeschlossen ist und im Debugger ausgeführt wird, gibt es keine Debug-Ausgabe, um zu sagen, warum wie bei einem "normalen" Absturz. Ich weiß, dass es nach einem LoadView passiert, weil ein NSLog am Ende von LoadView die letzte Ausgabe ist, auf dem gleichen Bildschirm jedes Mal. Unten ist der eingeschränkte Absturzbericht von Organizer ('unbekannter' Prozess, den ich denke, weil er im Debugger ausgeführt wurde?). Dies ist nur auf ios6 passiert. Es gibt anscheinend keine Speicherlecks nach dem Instrument, obwohl ich mir nicht sicher bin, ob ich es völlig vertraue. Der Absturz neigt dazu, zu passieren, wenn Sie das Spiel für eine Weile spielen und durch die Bildschirme hin und her gehen, so dass es sich wie ein Leck anfühlt. Die Tatsache, dass es immer zurückkehrt, wenn Sie zum selben Bildschirm zurückkehren, deutet jedoch darauf hin, dass es sich um ein Problem mit diesem View-Controller handelt. Ich weiß nicht, was rpages genau ist und ich weiß nicht, ob 90974 zu groß ist.

Incident Identifier: 7D34217C-9F8E-49B0-B399-1F5573355F31 
CrashReporter Key: 29ce6ea76874d5a03d826014a1f50e1a2160db41 
Hardware Model:  iPhone3,1 
OS Version:   iPhone OS 6.0 (10A403) 
Kernel Version:  Darwin Kernel Version 13.0.0: Sun Aug 19 00:27:34 PDT 2012; root:xnu-2107.2.33~4/RELEASE_ARM_S5L8930X 
Date:    2012-10-30 22:48:15 -0700 
Time since snapshot: 206 ms 

Free pages:  958 
Active pages:  2673 
Inactive pages: 2118 
Throttled pages: 101092 
Purgeable pages: 0 
Wired pages:  22186 
Largest process: MyCrashingApp 

Processes 
Name     <UUID>      rpages  recent_max  [reason]   (state) 

    MobileMail <bff817c61ce33c85a43ea9a6c98c29f5>   1165    1165   [vm]   (resume) (continuous) 
    MobilePhone <3fca241f2a193d0fb8264218d296ea41>  898    898   [vm]   (resume) (continuous) 
    tccd <eb5ddcf533663f8d987d67cae6a4c4ea>    119    119   [vm]   (daemon) 
    MyCrashingApp <f6c54a2392523abe8745d853870bf985>  90974   90974   [vm]   (audio) (frontmost) (resume) 
    ptpd <04a56fce67053c57a7979aeea8e5a7ea>    665    665      (daemon) 
    locationd <892cd1c9ffa43c99a82dba197be5f09e>   1237    1237      (daemon) 
    dataaccessd <2a3f6a518f3f3646bf35eddd36f25005>  614    614      (daemon) 
    mediaserverd <80657170daca32c9b8f3a6b1faac43a2>  1316    1316      (daemon) 
    syslogd <cbef142fa0a839f0885afb693fb169c3>   139    139      (daemon) 
    wifid <9472b090746237998cdbb9b34f090d0c>    284    284      (daemon) 
    iaptransportd <f784f30dc09d32078d87b450e8113ef6>  192    192      (daemon) 
    SpringBoard <27372aae101f3bbc87804edc10314af3>  3477    3477      
    backboardd <5037235f295b33eda98eb5c72c098858>   9957    9957      (daemon) 
    aggregated <8c3c991dc4153bc38aee1e841864d088>   75    75      (daemon) 
    BTServer <c92fbd7488e63be99ec9dbd05824f5e5>   198    198      (daemon) 
    configd <4245d73a9e96360399452cf6b8671844>   897    897      (daemon) 
    fairplayd.N90 <3ac48d9cfb143757bccce4fe6c154533>  135    135      (daemon) 
    fseventsd <996cc4ca03793184aea8d781b55bce08>   315    315      (daemon) 
    imagent <1e68080947be352590ce96b7a1d07b2f>   528    528      (daemon) 
    mDNSResponder <3e557693f3073697a58da6d27a827d97>  237    237      (daemon) 
    lockdownd <ba1358c7a8003f1b91af7d5f58dd5bbe>   207    207      (daemon) 
    powerd <2d2ffed5e69638aeba1b92ef124ed861>    123    123      (daemon) 
    UserEventAgent <6edfd8d8dba23187b05772dcdfc94f90>  427    427      (daemon) 
    debugserver <185719f06f1631d4922c652bdd4c8529>  0    0      (daemon) 
    gputoolsd <889065a15ba8372ca533e023c10bd776>   0    0      (daemon) 
    springboardservi <ff6f64b3a21a39c9a1793321eefa5304> 0    0      (daemon) 
    syslog_relay <45e9844605d737a08368b5215bb54426>  0    0      (daemon) 
    syslog_relay <45e9844605d737a08368b5215bb54426>  0    0      (daemon) 
    DTMobileIS <23303ca402aa3705870b01a9047854ea>   0    0      (daemon) 
    afcd <b0aff2e7952e34a9882fec81a8dcdbb2>    120    120      (daemon) 
    notification_pro <845b7beebc8538ca9ceef731031983b7 118    118      (daemon) 
    filecoordination <fbab576f37a63b56a1039153fc1aa7d8> 115    115      (daemon) 
    distnoted <a89af76ec8633ac2bbe99bc2b7964bb0>   101    101      (daemon) 
    apsd <94d8051dd5f5362f82d775bc279ae608>    280    280      (daemon) 
    networkd <0032f46009f53a6c80973fe153d1a588>   147    147      (daemon) 
    CommCenterClassi <c82f228b14a830cdb88e3cc1068330b3> 616    616      (daemon) 
    notifyd <51c0e03da8a93ac8a595442fcaac531f>   167    167      (daemon) 
    ReportCrash <8c32f231b2ed360bb151b2563bcaa363>  135    135      (daemon) 

End

Answer 1

Ihre App weil Jetsam abstürzt (a.k.a Speicherstatus), die iOS Bedingung für wenig Arbeitsspeicher Handler ist, tötet es (dies Linux OOM und Android LowMemory Killer-ähnlich ist). Was Sie sehen, ist der Speicher-Snapshot. Lassen Sie uns erklären:

 
Free pages:  958 - how much free physical memory (in multiples of 4K) 
Active pages:  2673 - how many pages in physical memory have recently been used 
Inactive pages: 2118 - how many pages in physical memory have NOT recently been used 
Throttled pages: 101092 - how many pages are subject to throttling (long story, irrelevant here) 
Purgeable pages: 0  - how many pages can be kicked out, on low memory condition 
Wired pages:  22186 - how many pages are resident locked, mostly for kernel purposes, or shared libraries 

Ihre App haben die unglückliche und zweifelhafte Ehre, die meist residenten Speicher (um Größenordnung im Vergleich zu anderen). Wenn also der Speicherschwache Zustand eintritt - einige App möchte einen großen Block malloc() haben, und nicht genug freie Seiten übrig bleiben - Jetsam wählt einfach den oberen Speicher und - Boom. Kill -9. Daher gibt es keinen Debug-Dump usw. iOS hat keinen Swap, daher gibt es keine Möglichkeit, Prozesse auf dem Swap abzulegen, um Speicher zu löschen. Der einzige Weg ist raus. Tod.

Was Sie dagegen tun können:

Vor Jetsam Sie tötet, gibt es in der Regel eine niedrige Speicher Benachrichtigung über ein Ereignis, das die Obj-C-Laufzeit in die -didReceiveMemoryWarning übersetzt. Also geh damit um. Von dem, was Sie beschreiben, möchten Sie vielleicht auch die UIView s freigeben. Diese verbrauchen viel Speicher.