2ème utilisation de NSURLConnection provoque SIGABRT iPhone

Question

J'ai beaucoup traqué les publications sur NSURLConnection et plus généralement sur le débogage SIGABRT mais je n'ai pas eu de joie là-dessus. Toute aide est grandement appréciée.

Ainsi, au début de mon application l'utilisateur est présenté en vue de connexion et sur la fourniture de nom d'utilisateur et mot de passe que je commence un NSURLConnection en procédant comme suit dans une classe LoginService:

-(void)loginWithURLRequest:(NSString*)requestString 
{ 
    if(self.mConnection == nil) 
    { 
     NSURLRequest* request = [NSURLRequest requestWithURL:[NSURL URLWithString:requestString] 
               cachePolicy:NSURLRequestUseProtocolCachePolicy 
              timeoutInterval:120.0]; 

     self.mConnection = [[[NSURLConnection alloc] initWithRequest:request delegate:self] autorelease]; 
    } 
} 

-(void)discardLoginDataAndPrepareToReceiveMore 
{ 
    // Releases old mLoginData and assigns a new empty one. 
    self.mLoginData = [[NSMutableData alloc] init]; 
} 

-(void)connection:(NSURLConnection*)connection didReceiveResponse:(NSURLResponse*)response 
{ 
    [self discardLoginDataAndPrepareToReceiveMore]; 
} 

-(void)connection:(NSURLConnection*)connection didReceiveData:(NSData*)data 
{ 
    [mLoginData appendData:data]; 
} 

-(void)connection:(NSURLConnection*)connection didFailWithError:(NSError*)error 
{ 
    [self discardLoginDataAndPrepareToReceiveMore]; 
    [mDelegate onLoginFailure:error]; 

    self.mConnection = nil; 
} 

-(void)connectionDidFinishLoading:(NSURLConnection*)connection 
{ 
    [mDataReader performSelector:mDataReaderSelector withObject:mLoginData]; 
    [mDelegate onLoggedInSuccessfully]; 

    self.mConnection = nil; 
} 

Donc tout cela fonctionne très bien. Le problème est plus tard j'essaie de POSTER une demande (à partir d'une classe différente) et peu de temps après l'application se bloque avec un SIGABRT dans une charge d'assemblage sur un thread séparé que je ne peux pas remonter à mon code. Je me rends compte de la NSURLConnection est exécuté sur un autre fil, etc.

donc je pensais que peut-être quelque chose de mal avec mon code postal et remplacé par le code de connexion exacte même connexion ci-dessous:

NSString* requestString = @"identical URL as before in login"; 

    NSURLRequest* request = [NSURLRequest requestWithURL:[NSURL URLWithString:requestString] 
              cachePolicy:NSURLRequestUseProtocolCachePolicy 
             timeoutInterval:120.0]; 

    self.mConnection = [[[NSURLConnection alloc] initWithRequest:request delegate:self] autorelease]; 

Même problème, donc mon Le dernier essai a été de voir si le premier login brouillait les choses. c'est-à-dire que je ne connaissais pas les connexions et que je ne nettoyais pas correctement etc. J'ai donc désactivé le 1er login et laissé ma 2ème entrée et puis ça marche bien et je reçois mes callbacks dans les méthodes de délégué etc.

Des conseils sur ce que je pourrais faire de mal. Il semble y avoir quelque chose que je ne fais pas pendant/après la première connexion qui provoque le crash de la seconde.

Je peux passer la 2ème connexion NSUR dans l'application lorsque la première connexion est toujours présente. Le plantage réel se produit peu après avoir dit à l'application de continuer après que cette connexion soit établie. Dans les deux cas, la mConnexion est une propriété (non atomique, conservée) de chaque classe, respectivement.

Je me rends compte qu'il y a de meilleures façons de gérer plusieurs connexions (après ma recherche) que je devrai utiliser de toute façon bientôt, mais je dois le faire fonctionner pour une démo pour un client et je suis aussi curieux de savoir se passe mal au cas où cela implique un malentendu plus fondamental des connexions etc de ma part. Humm, je suppose aussi que je manque également de connaissances sur la façon dont je devrais aller sur le débogage. Tous les conseils d'instruments pour cela seraient appréciés. J'ai évité d'utiliser des allocations dans l'outil de performance puisque SIGABRT n'est pas un problème causé par des fuites si ma compréhension est correcte?

De plus, voici la pile d'appel:

- # 0 0x90d7e132 à tuer
- # 1 0x90d7e124 Kill Unix 2003. $
- # 2 0x90e108e5 en augmentation
- # 3 0x90e2699c dans abort
- # 4 0x90d23d35 en libre
- # 5 0x026fc081 dans __CFStringDeallocate
- N ° 6 0x026fbccb dans _CFRelease
- # 7 0x02720c9d dans _CFAutoreleasePoolPop
- # 8 0x0004fe67 dans - [libération NSAutoreleasePool]
- # 9 0x00300e7f dans _UIApplicationHandleEvent
- # 10 0x030c4822 dans PurpleEventCallback
- # 11 0x027c5ff4 dans __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION
- # 12 0x02726807 dans __CFRunLoopDoSource1
- # 13 0x02723a93 dans __CFRunLoopRun
- # 14 0x02723350 dans CFRunLoopRunSpecific
- # 15 0x02723271 dans CFRunLoopRunInMode
- # 16 0x030c300c dans GSEventRunModal
- # 17 0x030c30d1 dans GSEve ntRun
- # 18 0x00304af2 dans UIApplicationMain
- # 19 0x0000242c dans le principal à main.m: 14

Je suppose que cela signifie (quand je regarde mon commentaire ci-dessous aussi) que je ne demande pas alloc sur quelque chose (peut-être une chaîne) avant de le libérer?

Answer 1

Avez-vous exécuté votre application avec des zombies activés? C'est peut-être une over-release, que les zombies vont ramasser. Une autre façon de suivre cette baisse serait d'activer l'historique de malloc, et de vérifier d'où vient le mauvais pointeur (0x818c0b0 dans votre commentaire).

Cela peut être utile pour vous: iPhone - debugging "pointer being freed was not allocated" errors

Il semble que la mémoire est corrompue à l'intérieur d'un objet CFString/NSString, ce qui signifie qu'il pourrait se produire quelque part qui semble tout à fait sans rapport. Vous pourriez passer un mauvais pointeur dans un NSString, donc vous pourriez vouloir vérifier pour cela aussi.

En outre, quelle est la valeur de mDataReaderSelector? Si vous faites un performSelector: et la méthode renvoie une structure (par exemple NSRect) qui peut éventuellement corrompre la mémoire. C'est long, mais je pensais vérifier de toute façon.

Answer 2

Il est difficile de localiser sans l'intégralité de la source, mais il semble que vous appelez une seconde version (et non valide) sur un objet NSString. Jetez un oeil à la façon dont vous traitez les chaînes tout au long de votre projet. Assurez-vous qu'ils ont l'attribut 'copy' dans vos déclarations de propriété et que vous ne libérez pas inutilement ceux qui sont déjà autoeleased. (c'est-à-dire ceux avec créé [NSString stringWithFormat:])

Answer 3

corrigé après l'activation de Zombie (que je pensais suivre uniquement les fuites et non les doubles libres/autoreleases). J'autoreleasing une chaîne qui n'en avait pas besoin. Grâce à TomDalling et à drowntoge, vous étiez tous les deux sur la bonne voie grâce à

Je viens juste d'y arriver et j'ai vu vos réponses (comme je le signalais) qui, à coup sûr, m'auraient amené là de toute façon. Je n'étais pas au courant que stringWithFormat autoreleased et autoreleasing un de toute façon. Seulement vraiment commencé juste à utiliser la libération automatique et utilisé pour attribuer aux locaux et les libérer après avoir attribué ce local à mes propriétés retenues. Ce qui est aussi bien juste pas si bien rangé dans le code. Je suppose que j'ai eu beaucoup de fuites avant que je ne savais pas. J'avais lu les docs sur la mémoire il y a quelques temps mais je n'ai jamais utilisé la autorelease, donc je pense que je dois y revenir :-)

Je ne sais toujours pas comment la connexion initiale a manifesté le problème La 2ème connexion est un bon moment plus tard. Complètement m'a jeté comme je pensais que c'était à propos de ma compréhension des connexions. La chaîne en question se trouvait dans et autour de ce code. hmm de toute façon, vive les gars.