2013-02-19 16 views
5

Ho visto questo rapporto di arresto anomalo alcune volte. È estremamente casuale e raro, e non riesco a capirlo. Tutto quello che sto facendo sta presentando un controller di vista modale utilizzando il seguente codiceArresto anomalo quando si presenta modale UIViewController

ComposeController *newcontrol = [[ComposeController alloc]initWithMode:1 withNIB:@"ComposeController"]; 
newcontrol.delegate = self; 

UINavigationController *holder = [[UINavigationController alloc] initWithRootViewController:newcontrol]; 
[self presentViewController:holder animated:YES completion:NULL]; 

In qualche modo questo porta a questo completamente a caso:

OS Version:  iPhone OS 6.1 (10B143) 
Report Version: 104 

Exception Type: SIGSEGV 
Exception Codes: SEGV_ACCERR at 0x9 
Crashed Thread: 0 

Thread 0 Crashed: 
0 libobjc.A.dylib      0x3b25c5d0 objc_msgSend + 16 
1 CoreFoundation      0x334ba73f -[__NSPlaceholderArray initWithObjects:count:] + 271 
2 CoreFoundation      0x334bae09 +[NSArray arrayWithObject:] + 45 
3 UIKit        0x353e80ab -[UIWindow _rotationViewControllers] + 51 
4 UIKit        0x353e7fe3 -[UIViewController viewControllerForRotation] + 91 
5 UIKit        0x353e7f39 -[UIViewController _visibleView] + 97 
6 UIKit        0x3546c05b -[UIWindowController transition:fromViewController:toViewController:target:didEndSelector:] + 2483 
7 UIKit        0x3546afab -[UIViewController presentViewController:withTransition:completion:] + 3399 
8 MyApp        0x00046e97 -[Inbox composeHit] (Inbox.m:207) 

risposta

-2

Prova a fare questo

[pushViewController titolare: newcontrol animato : SÌ completamento: NULL];

4

Ho lo stesso problema abbastanza consistentemente. Sembra essere causato dal fatto che sto presentando un controller di visualizzazione modale da un popover, che non è ben testato e fa scattare un bug nel codice Apple. Il bug è che UIKit mantiene un riferimento non ritoccato al mio View Controller che è stato già eliminato e deallocato, quindi in un momento successivo tale riferimento viene colpito. La mia soluzione alternativa è quella di evitare di presentare VC modali da un popover, o di conservare tutti questi VC da solo indefinitamente (in una variabile membro o qualcosa del genere).

Di seguito sono riportati i dettagli sanguinosi.

Ecco il codice che ho utilizzato per attivare il problema.

-(void) handlePinchFromCell:(AMPSupportingPhotoCell*) cell 
{ 
    UIViewController * vc = [[UIViewController alloc] init]; // UIViewController #0 
    [self presentViewController:vc animated:YES completion:nil]; 
    [self performSelector:@selector(dismiss:) withObject:vc afterDelay:2]; 
} 

-(void) dismiss:(UIViewController*)vc 
{ 
    [self dismissViewControllerAnimated:YES completion:^(){NSLog(@"-------");}]; 
} 

Questo codice è una parte di un UIViewController # 1, che si trova all'interno di un UIPopoverController, che viene estratto nel corso di un altro UIViewController # 2, che è essa stessa un presentato da un altro vista UIViewController 3 #. L'arresto si verifica dopo che il popover è stato chiuso, l'id del controller n. 2 è stato chiuso.

Se abilito Zombies, ottengo lo stesso stack trace, ma con un messaggio:

2013-03-13 20:04:24.681 Mercury[16698:19d03] handlePinchFromCell: a225710 
2013-03-13 20:04:27.083 Mercury[16698:19d03] ------- 
2013-03-13 20:04:31.606 Mercury[16698:19d03] *** -[UIViewController retain]: message sent to deallocated instance 0xa225710 

Quindi, si noti che il VC# 0 ottenuto allocato, ha presentato, ha respinto 2 secondi più tardi, deallocato, eppure c'è è ancora un riferimento ciondolante da qualche parte nel codice di Apple. Quando il popover è chiuso e VC# 2 viene eliminato, l'intera operazione si arresta in modo anomalo cercando di accedere al VC deallocato. Sono abbastanza certo che questo è un bug di Apple. Immagino anche che sia legato alla presentazione di un VC da un popover, quindi se stai lontano da questo, o mantieni il VC da solo, dovresti stare bene.

Un'altra traccia dello stack per lo stesso problema è questa. Succede se il codice sopra riportato viene eseguito due volte:

2013-03-13 20:12:53.883 Mercury[16735:19d03] handlePinchFromCell: 16d54da0 
2013-03-13 20:12:56.285 Mercury[16735:19d03] ------- 
2013-03-13 20:13:03.481 Mercury[16735:19d03] handlePinchFromCell: a2565f0 
2013-03-13 20:13:03.481 Mercury[16735:19d03] *** -[UIViewController isKindOfClass:]: message sent to deallocated instance 0x16d54da0 
(lldb) bt 
* thread #1: tid = 0x1f03, 0x017f8a97 CoreFoundation`___forwarding___ + 295, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0) 
    frame #0: 0x017f8a97 CoreFoundation`___forwarding___ + 295 
    frame #1: 0x017f894e CoreFoundation`_CF_forwarding_prep_0 + 14 
    frame #2: 0x00c42f90 UIKit`-[UIWindowController transition:fromViewController:toViewController:target:didEndSelector:] + 907 
    frame #3: 0x00a40ee3 UIKit`-[UIViewController presentViewController:withTransition:completion:] + 4521 
    frame #4: 0x00a41167 UIKit`-[UIViewController presentViewController:animated:completion:] + 112 
    frame #5: 0x0006c32d Mercury`-[AMPSupportingPhotosViewController handlePinchFromCell:](self=0x16d55360, _cmd=0x0007a64a, cell=0x0a22a2a0) + 205 at AMPSupportingPhotosViewController.m:184 
    frame #6: 0x015336b0 libobjc.A.dylib`-[NSObject performSelector:withObject:] + 70 
    frame #7: 0x0006f317 Mercury`-[AMPSupportingPhotoCell handlePinch:](self=0x0a22a2a0, _cmd=0x00efb0db, sender=0x0a2504a0) + 215 at AMPSupportingPhotoCell.m:53 
    frame #8: 0x00c2185a UIKit`_UIGestureRecognizerSendActions + 139 
+0

interessante. Nel mio caso, sto presentando un controller di visualizzazione modale da un altro controller di visualizzazione modale. Lo stesso problema che pensi? Vengono sempre deallocati nell'ordine corretto ma in base a quello che stai dicendo sembra che se qualcuno dice hit cancel sul primo controller modale e poi premi rapidamente cancel sul controller modale originale che potrebbe innescare un crash? –

+0

Penso che sia la stessa cosa - un VC che si blocca da qualche parte nel sistema Apple. – DenNukem