Afnetworking: Bug iOS 11.3

[narlei]

In the last iOS 11.3 Beta, when the return code is 204 (no content) the body return nil.
Then a error shows:

````
if (success) {
dispatch_group_async(self.completionGroup ?: http_request_operation_completion_group(), self.completionQueue ?: dispatch_get_main_queue(), ^{
success(self, responseObject); <- here
});
}

````
File AFHTTPRequestOperation.m line 137

[SlaunchaMan]

What’s the error message?

[narlei]

no error shows in Console

[SlaunchaMan]

Based on the error in Xcode it looks like either success, self, or responseObject have been set to nil between when dispatch_group_async() is called and when the block actually runs. Based on the 204 status code, it’s probably responseObject. I’ll look into this.

[narlei]

@SlaunchaMan the responseObject is null because status 204 is no content. But this error is only in iOS Beta :(

[berkcebi]

Hey hey!

I did run into the same issue (with no content responses only) on 2.6.3. It seems to be working fine on 3.2.0 though, will migrate.

Here's a stack trace, just in case:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00000001027db36f libswiftCore.dylib`swift_getObjectType + 47
    frame #1: 0x000000010006d05e Zeplin Debug`thunk for @escaping @callee_guaranteed (@owned URLSessionDataTask, @in Any) -> () at OrganizationController+OrganizationActions.swift:0
  * frame #2: 0x0000000101af7504 AFNetworking`__84-[AFHTTPSessionManager dataTaskWithHTTPMethod:URLString:parameters:success:failure:]_block_invoke.91(.block_descriptor=0x0000604000e64600, response=0x000060000023b380, responseObject=0x0000000000000000, error=0x0000000000000000) at AFHTTPSessionManager.m:252
    frame #3: 0x0000000101b18d49 AFNetworking`__72-[AFURLSessionManagerTaskDelegate URLSession:task:didCompleteWithError:]_block_invoke_2.71(.block_descriptor=0x00006040004867c0) at AFURLSessionManager.m:202
    frame #4: 0x0000000102efecfe libdispatch.dylib`_dispatch_call_block_and_release + 12
    frame #5: 0x0000000102ef6ddf libdispatch.dylib`_dispatch_client_callout + 8
    frame #6: 0x0000000102f02fa0 libdispatch.dylib`_dispatch_main_queue_callback_4CF + 876
    frame #7: 0x00007fff2c52ec69 CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
    frame #8: 0x00007fff2c4f0e4a CoreFoundation`__CFRunLoopRun + 2586
    frame #9: 0x00007fff2c4f01a3 CoreFoundation`CFRunLoopRunSpecific + 483
    frame #10: 0x00007fff2b7d8d96 HIToolbox`RunCurrentEventLoopInMode + 286
    frame #11: 0x00007fff2b7d8b06 HIToolbox`ReceiveNextEventCommon + 613
    frame #12: 0x00007fff2b7d8884 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
    frame #13: 0x00007fff29a8ba73 AppKit`_DPSNextEvent + 2085
    frame #14: 0x00007fff2a221e34 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044
    frame #15: 0x00007fff29a80885 AppKit`-[NSApplication run] + 764
    frame #16: 0x00007fff29a4fa72 AppKit`NSApplicationMain + 804
    frame #17: 0x00000001003c732d Zeplin Debug`main at AppDelegate.swift:22
    frame #18: 0x00007fff5480a015 libdyld.dylib`start + 1

[petrpavlik]

We've started experiencing the same using AFNetworking 3.2.0, 204 responses with an empty body suddenly start returning nil responseObject when compiled using Xcode 9.3 stable.

[laposheureux]

Not seeing this for all empty responses. Currently seeing a crash with an empty body response from a PUT but not from a DELETE.

Xcode 9.3 release, AFNetworking 3.2.0.

[SlaunchaMan]

Looking at the interface in 3.2.0, it looks like all responseObject parameters in AFHTTPSessionManager.h are marked as _Nullable; further, the tests do account for 204 status codes with empty bodies and the responseObject is nil for those. I’m using HTTPBin to test this, and I can’t reproduce a crash. @petrpavlik or @laposheureux, any ideas on what’s different about what you’re calling?

[gorjuspixels]

This seems to be fixed in https://github.com/AFNetworking/AFNetworking/pull/3292 (checking if mime type is nil). I'm still using 2.6.3 and I fixed it by using AFCompoundResponseSerializer like it was suggested in https://github.com/AFNetworking/AFNetworking/issues/2797. I'm wondering if @narlei is using some custom response serializer that might be causing this?

[greenmood]

We have the same issue, DELETE method, 2.6.3 AFNetworking, Xcode 9.3.1 Using _AFCompoundResponseSerializer_ didn't help.

[SlaunchaMan]

@greenmood Is the issue that the responseObject is coming back nil or something else? Can you reproduce it in a sample project I could look at?

[greenmood]

@SlaunchaMan Yes. My use case was to send a DELETE request in viewWillDissappear, server then responds with 204 and responseObject is nil.
I'll try to create a sample project later this week. For now, I'll be using Apple's default URLSessionDataTask.

[SlaunchaMan]

The responseObject is marked as _Nullable in the code: https://github.com/AFNetworking/AFNetworking/blob/master/AFNetworking/AFURLSessionManager.h#L225

You should be able to handle nil in this case.

[greenmood]

Then maybe it's related to viewcontroller being deallocated after async operation finishes. If the same code is executed in viewDidLoad, it works

[SlaunchaMan]

That seems likely to me. Are you by any chance using Swift, with @IBOutlets marked as implicitly unwrapped optionals? That’s a common cause of crashes—if the view controller is deallocated but there’s a non-owning reference to the outlet in a completion handler, you’d crash when trying to unwrap it.

[greenmood]

Can be, viewcontroller is in swift, but uses iboutlets from objc for displaying cells in tableview.

[nyeu]

Hi! I am having this same issue, when a call returns a 204 the app crashes. This wasn't crashing before, it's since we compiled it with Xcode 9.3 and 9.4. Any solutions/workaround?
Thank you

[giilby]

We ran into this issue with v2.6.3. I believe the problem is that some methods in AFHTTPRequestOperationManager.h should be marking responseObject as __nullable, but currently aren't. For example, a POST could return 204 No Content, but none of the POST: methods in AFHTTPRequestOperationManager.h allow responseObject to be nil, which causes interoperability problems with Swift. Notably, v3.2.1 fixes this issue. @SlaunchaMan, I'm happy to submit a PR to backport the fixes to v2.x if you think it makes sense.

[SlaunchaMan]

@giilby Sure, if there are already nullability annotations in the 2.6 branch, I’d have no problem releasing an update to it for people who haven’t yet (or can’t) update to 3.2. If these would be the first annotations then we’d have to make sure it doesn’t break for existing users (maybe a 2.7 branch?).

[quintonpryce]

For the time being, you can fix this by serializing your operation.
let op = self.manager.post("myURL.com/set_the_goods", parameters: params, success: { _, _ in completionHandler(nil) }, failure: { _, error in completionHandler(error) }) op?.responseSerializer = AllowsEmptyArrayResponseSerializer()

[jcravioto]

Hi, I'm still using version 2.6.3 and this crash is holding me back and I'm not ready to migrate to 3.0 yet. I've tested a change to allow __nullable on objectResponse for post method on AFHTTPSessionManager and it works great. I'll be happy to contribute if that's not a problem. Could it be possible to push a 2.7 version after it?

[SlaunchaMan]

@jcravioto Sure, send a PR against the 2.6 branch and I’d be happy to look at it!

[liuxuan30]

just wonder has this been fixed in 3.x release?

[stale[bot]]

This issue has been marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale[bot]]

This issue has been auto-closed because there hasn't been any activity for at least 21 days. However, we really appreciate your contribution, so thank you for that! 🙏 Also, feel free to open a new issue if you still experience this problem 👍.