第二次使用NSURLConnection会导致SIGABRT iPhone [英] 2nd use of NSURLConnection causes SIGABRT iPhone

问题描述

关于NSURLConnection和更一般的SIGABRT调试，我已经在很多地方找了很多，但是对此并不高兴。

I have hunted around a lot on posts to do with NSURLConnection and more generally SIGABRT debugging but have had no joy on this. Any help is greatly appreciated.

因此，在我的应用程序启动时，向用户显示一个登录视图，并在提供用户名和密码时通过执行以下操作启动NSURLConnection LoginService类中的以下内容：

So, at the start of my app the user is presented with a login view and on supplying user name and password I start an NSURLConnection by doing the following in a LoginService class:

-(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;
}

所以这一切都很好。问题是稍后我尝试发布请求（来自不同类），然后不久，应用程序崩溃，SIGABRT在单独线程上的程序集加载中崩溃，而我无法追溯到我的代码。我意识到NSURLConnection是在另一个线程上运行的。

So this all works just fine. Problem is later I try to POST a request (from within a different class) and shortly afterwards the app crashes with a SIGABRT in a load of assembly on a separate thread which I cannot trace back to my code. I realise the NSURLConnection is run on another thread etc.

所以我认为我的邮政编码可能有误，并用下面完全相同的登录连接代码代替了： / p>

So I thought maybe it's something wrong with my post code and replaced it with the exact same login connection code below :

    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];

同样的问题，所以我的最后尝试是看第一次登录是否以某种方式弄乱了东西。例如，也许我对连接一无所知，无法正确清理等。于是，我禁用了第一个登录名，并留下了第二个登录名，然后工作正常，我在委托方法等中得到了回调。

Same problem, so my last try was to see if somehow the 1st login was messing things up. i.e. maybe I didn't know something about connections and was not cleaning up properly etc. So I disabled the 1st login and left my 2nd one in and then it works fine and I get my callbacks in the delegate methods etc.

关于我可能做错的任何提示。似乎在建立第一个连接期间/之后，我没有做任何事情，导致第二个崩溃。

Any tips on what I could be doing wrong. There seems to be something I am not doing during/after the 1st connection is made that causes the second to crash.

我可以在应用程序中跳过第二个NSURConnection时第一次登录仍然存在。真正的崩溃发生在告诉应用建立此连接后继续运行之后不久。

I can step over the 2nd NSURConnection in the app when the 1st login is still present. The actual crash occurs shortly after telling the app to continue after this connection is made.

在两种情况下，mConnection分别是每个类的（非原子的，保留的）属性。

In both cases the mConnection is a (nonatomic, retained) property of each class respectively.

我意识到有更好的方式来处理多个连接（在搜索之后），无论如何我都需要尽快使用它，但是我需要将此方法用于为客户进行演示，并且对发生什么问题也感到好奇，以防万一这意味着我对连接等有更根本的误解。

I realise that there are better ways of handling multiple connections (after my searching around) which I will need to employ soon anyway, but I need to get this working for a demo for a client and am also curious as to what is going wrong in case it implies a more fundamental misunderstanding of connections etc on my part.

嗯，我想我也缺乏关于如何调试它的知识。任何仪器提示对此将不胜感激。我避免在性能工具中使用分配，因为如果我的理解正确的话，SIGABRT并不是由泄漏引起的问题？

Hmm, I guess also I also lacking knowledge about how I should go about debugging this. Any instruments tips for this would be appreciated. I avoided using allocations in the performance tool since SIGABRT is not an issue caused by leaks if my understanding is correct?

另外，这里是调用堆栈：

Additionally here's the call stack:

-＃0 0x90d7e132在 kill

-＃1 0x90d7e124在kill $ UNIX2003

- ＃2 0x90e108e5提高中

-＃3 0x90e2699c中止

-＃4 0x90d23d35免费中

-＃5 0x026fc081 in __CFStringDeallocate
_CFRelease中的
-＃6 0x026fbccb
$ _CAutoreleasePoolPop中的
-＃7 0x02720c9d

-＃8 0x0004fe67在-[NSAutoreleasePool版本]

-＃9 0x00300e7f in _UIApplicationHandleEvent

-＃10 0x030c4822 in PurpleEventCallback

-＃11 0x027c5ff4 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION
-b $ b $ __CFRunLoopDoSource1中的0x02726807

-＃13 __CFRunLoopRun中的0x02723a93

-＃14 CFRunLoopRunSpecific中的0x02723350
-＃ 15 0x02723271在CFRunLoopRunInMode中

-＃16 0x030c300c在GSEventRunModal中

-＃17 0x030c30d1在GSEventRun

-＃18 0x00304af2在UIApplicationMain中

-＃19 0x0000242c main位于main.m：14

-#0 0x90d7e132 in kill
-#1 0x90d7e124 in kill$UNIX2003
-#2 0x90e108e5 in raise
-#3 0x90e2699c in abort
-#4 0x90d23d35 in free
-#5 0x026fc081 in __CFStringDeallocate
-#6 0x026fbccb in _CFRelease
-#7 0x02720c9d in _CFAutoreleasePoolPop
-#8 0x0004fe67 in -[NSAutoreleasePool release]
-#9 0x00300e7f in _UIApplicationHandleEvent
-#10 0x030c4822 in PurpleEventCallback
-#11 0x027c5ff4 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION
-#12 0x02726807 in __CFRunLoopDoSource1
-#13 0x02723a93 in __CFRunLoopRun
-#14 0x02723350 in CFRunLoopRunSpecific
-#15 0x02723271 in CFRunLoopRunInMode
-#16 0x030c300c in GSEventRunModal
-#17 0x030c30d1 in GSEventRun
-#18 0x00304af2 in UIApplicationMain
-#19 0x0000242c in main at main.m:14

我认为这意味着（当我还会在下面看到我的评论），我在释放它之前没有在某个东西（也许是字符串）上调用alloc吗？

I assume that this means (when I look at my comment below also) that I am not calling alloc on something (maybe a string) before I release it?

推荐答案

在启用Zombie之后修复（我认为它仅跟踪漏洞，也没有两次释放/自动发布）。我正在自动释放不需要的字符串。

fixed after enabling Zombie (which I thought only tracked leaks and not also double frees/autoreleases). I was autoreleasing a string that didn't need it.

感谢TomDalling和drowntoge，你们俩都走对了。我刚到那里，然后看到了您的答案（正如我在发布此信息一样），无论如何肯定可以使我到那里。我不知道stringWithFormat是自动发布的，而且还是会自动释放。只有真正开始使用自动释放，然后才用于分配给本地，然后在将所述本地分配给我的保留属性后释放它们。这也很好，只是代码没有那么整洁。我想我之前不知道有很多泄漏。我曾经读过有关内存的文档，但从未使用过自动释放功能，所以我想我需要再次回顾一下它们：-）

Thanks to TomDalling and drowntoge, you were both on the right tracks. I just got there then saw your answers (as I was posting this)which for sure would have got me there soon anyway. I was not aware that stringWithFormat autoreleased and was autoreleasing one anyway. Only really just started using auto release and used to assign to locals and release them after assigning said local to my retained properties. Which is also fine just not so tidy in code. I guess i had a lot of leaks before that I was unaware of. I had read the docs on memory stuff a while back but just never used the autorelease so I think I need to go back over them again :-)

仍然不知道启用后，初始连接如何表现出问题，因为第二个连接在以后比较好。我以为这完全是我对联系的理解，这使我全神贯注。所讨论的字符串在此代码中及周围。嗯，b
，欢呼。

Still have no idea how the initial connection manifested the problem when enabled since the 2nd connection is a good while later. Completely threw me as I thought it was all about my understanding of connections. The string in question was in and around this code though. hmm anyway, cheers guys.

这篇关于第二次使用NSURLConnection会导致SIGABRT iPhone的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！