After updating to v2.4.x I've seen a large amount of crashes from users all running iOS 7.1.x. There were no issues with v2.3.x.
The methods where the crashes occur include:
I'm looking into it more and will try to re-create the issue. I just wanted to get the issue logged.
I haven't seen any other reports similar to this. Are there any updates on your end?
We use AFNetworking 2.4.1 in the project, and the most popular crash now is this one, looks similar:

Same for us. After switching to AFNetworking 2.0 we are regularly seeing crashes in AFURLSessionManager[line 212]:
- (void)URLSession:(__unused NSURLSession *)session
dataTask:(__unused NSURLSessionDataTask *)dataTask
didReceiveData:(NSData *)data
{
[self.mutableData appendData:data];
}
In the debugging console we sometimes get the following:
malloc: *** error for object 0x633c000: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
However, tried to debug it for quite some time and couldn't find the root cause. There is no way to reliably reproduce the problem.
Let you know if I get any clue what this could be.
I ended up rolling back to 1.3.x 2.3.x. When I was trying it the crash happened
pretty often. After the holiday I'lol try upgrading to 1.5 2.5 to see if it's
still happening, and if it is see if I can make a sample project that
re-creates it.
I'm sorry I typed it wrong. I meant 2.3 and 2.5.
Yes, I'm seeing the exact same issue. Do we know in which version does this appeared?
It started for us in v2.4.0.
Yes, I suspected so, we never saw it before 2.4.0 neither. So for the time being we have rolled back to 2.3.0.
Updating to 2.5 seems to have fixed the issue I was having. I'll report back once I send it out to our beta testers.
Updating to 2.5 didn't completely solve the problem for us. It just happens very rarely now.
We also rolled back to 2.3.1 for the time being. Don't see any crashes with 2.3.1.
Nope, we're still seeing this issue for iOS 7 users. We're rolling back to 2.3.1 until we drop iOS 7 support completely.
Don't know if it's helpful, but we have the same issue. Rolling back to 2.3.1 since it seems to be working for other people here.

This is our 2nd highest crash, 2.5.0, 100% iOS 7. (About to become our highest crash cuz I just fixed our highest one)

We're also considering rolling back to 2.3.1 because of the iOS7 crashes. For those who have done this already, are there any issues? 2.3.1 predates iOS 8, so we're a little concerned about going back to that release.
Didn't have any problems on our side so far - 2.3.1 seems to be rock solid.
Am 03.02.2015 um 20:40 schrieb skochan [email protected]:
We're also considering rolling back to 2.3.1 because of the iOS7 crashes. For those who have done this already, are there any issues? 2.3.1 predates iOS 8, so we're a little concerned about going back to that release.
—
Reply to this email directly or view it on GitHub.
Thanks for the quick reply.
Sent from my iPhone
On Feb 3, 2015, at 11:42 AM, Jens Dressler [email protected] wrote:
Didn't have any problems on our side so far - 2.3.1 seems to be rock solid.
Am 03.02.2015 um 20:40 schrieb skochan [email protected]:
We're also considering rolling back to 2.3.1 because of the iOS7 crashes. For those who have done this already, are there any issues? 2.3.1 predates iOS 8, so we're a little concerned about going back to that release.
—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHub.
Same here with 2.5.4 version
I got this problem frequency on iOS 7.1
Xcode terminal:
malloc: *** error for object 0x7fafc40c6560: pointer being realloc'd was not allocated
*** set a breakpoint in malloc_error_break to debug
fabric:
Crashed: NSOperationQueue 0x170228940 SIGABRT ABORT at 0x000000019a9e658c
Thread : Crashed: NSOperationQueue 0x170228940
0 libsystem_kernel.dylib 0x000000019a9e658c __pthread_kill + 8
1 libsystem_pthread.dylib 0x000000019aa6916c pthread_kill + 104
2 libsystem_c.dylib 0x000000019a97a808 abort + 112
3 libsystem_malloc.dylib 0x000000019aa15834 malloc_zone_realloc + 414
4 Foundation 0x000000018e8a6e70 _NSMutableDataGrowBytes + 292
5 Foundation 0x000000018e8a6c84 -[NSConcreteMutableData appendBytes:length:] + 376
6 Foundation 0x000000018ea524b8 __49-[_NSDispatchData enumerateByteRangesUsingBlock:]_block_invoke + 44
7 libdispatch.dylib 0x000000019a8d09cc _dispatch_client_callout3 + 16
8 libdispatch.dylib 0x000000019a8d0928 _dispatch_data_apply + 128
9 libdispatch.dylib 0x000000019a8d3750 dispatch_data_apply + 44
10 Foundation 0x000000018ea52480 -[_NSDispatchData enumerateByteRangesUsingBlock:] + 68
11 Foundation 0x000000018e8a6ae4 -[NSConcreteMutableData appendData:] + 88
12 Haioo 0x0000000100206f74 -[AFURLSessionManagerTaskDelegate URLSession:dataTask:didReceiveData:] (AFURLSessionManager.m:212)
13 Haioo 0x000000010020bb80 -[AFURLSessionManager URLSession:dataTask:didReceiveData:] (AFURLSessionManager.m:1043)
14 Foundation 0x000000018e8aba84 -[NSBlockOperation main] + 76
15 Foundation 0x000000018e898a20 -[__NSOperationInternal _start:] + 644
16 Foundation 0x000000018e95aa38 __NSOQSchedule_f + 76
17 libdispatch.dylib 0x000000019a8cffd4 _dispatch_client_callout + 16
18 libdispatch.dylib 0x000000019a8d5654 _dispatch_async_redirect_invoke + 152
19 libdispatch.dylib 0x000000019a8cffd4 _dispatch_client_callout + 16
20 libdispatch.dylib 0x000000019a8d72b8 _dispatch_root_queue_drain + 556
21 libdispatch.dylib 0x000000019a8d74fc _dispatch_worker_thread2 + 76
22 libsystem_pthread.dylib 0x000000019aa656bc _pthread_wqthread + 356
23 libsystem_pthread.dylib 0x000000019aa6554c start_wqthread + 4
Is there any way avoid this except rolling back?
I'm still not entirely sure of the issue here.
I do want to note that we removing support for NSURLConnection in 3.0.0, and relying exclusively on NSURLSession since Apple has deprecated NSURLConnection, so would go away on that front once you migrate to AFHTTPSessionManager.
I'm going to leave this open for now in hopes we can get more information on if this is still a problem or not.
There's a similar issue involving some of the same lines here: https://github.com/AFNetworking/AFNetworking/issues/2900
We upgraded to AFNetworking 3.0 and this is still our #1 production crash, 99% on iOS 7. Can we do anything to help moving this bug forward?
Still a issue for us with AFNetworking 3.0.4 for 98% of users on iOS 7
Guys, this is still a prevalent crash in iOS 7. Anyone even care here?

@kcharwood this issue is caused by
[self.mutableData appendData:data];//line 326 in AFURLSessionManager
In iOS 7.1.x, selector(appendData:) is a asynchronous method. After [NSURLSessionDataTaskDelegate didReceiveData], [NSURLSessionTaskDelegate didCompleteWithError] will be called.While self.mutableData is appending data,if [delegate URLSession:session task:task didCompleteWithError:error] is called and self.mutableData = nil in another thread, origin self.mutableData pointer point to a bad address.

//checking the systemVersion in line 268 seems fix it.
if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 8.0) {
self.mutableData = nil;
}
Hope that helps!:) @pocketlim @estebanuribe @leslie-lei
@Jiangmx Thanks for the insights on that. Ended up attempting changing AFURLSessionManager's maxConcurrentOperationCount to 1 for iOS 7 users and so far the crash numbers seems significantly lower.
@estebanuribe it seems no use setting maxConcurrentOperationCount = 1, I got the same crash stack on iOS8.3.
if (self.mutableData) {
data = [self.mutableData copy];
//We no longer need the reference, so nil it out to gain back some memory.
[self.lock lock];
self.mutableData = nil;
[self.lock unlock];
}
I setting maxConcurrentOperationCount = 1 and write
if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 8.0) {
self.mutableData = nil;
}
in line 268 seems fix it.
So what should we do with it?
if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 8.0) {
self.mutableData = nil;
}
seems not work,still got lots of crash.

#pragma mark - NSURLSessionTaskDelegate
- (void)URLSession:(__unused NSURLSession *)session
task:(NSURLSessionTask *)task
didCompleteWithError:(NSError *)error
{
...
//Performance Improvement from #2672
NSData *data = nil;
if (self.mutableData) {
data = [self.mutableData copy];
//We no longer need the reference, so nil it out to gain back some memory.
@synchronized (self.mutableData) {
self.mutableData = nil;
}
}
...
}
在崩溃的地方加锁,我这边崩溃现象基本没有了。
Closing as this issue is very old. If there are newer crash reports, please open new issues.
Most helpful comment
@kcharwood this issue is caused by
[self.mutableData appendData:data];//line 326 in AFURLSessionManager
In iOS 7.1.x, selector(appendData:) is a asynchronous method. After [NSURLSessionDataTaskDelegate didReceiveData], [NSURLSessionTaskDelegate didCompleteWithError] will be called.While self.mutableData is appending data,if [delegate URLSession:session task:task didCompleteWithError:error] is called and self.mutableData = nil in another thread, origin self.mutableData pointer point to a bad address.
//checking the systemVersion in line 268 seems fix it.
Hope that helps!:) @pocketlim @estebanuribe @leslie-lei