1
votes

I'm getting a crash caused by AFNetworking at least that's where the stack trace (below) is pointing me. I've currently 457 crashes for this problem but this is small enough compared to the amount of users the app gets.

Version: 1.1.0. (I'm about 11 months out of date)

I've today updated to 1.3.3. Updating to 2.0 is on the cards but just bit bureaucracy to deal with.

The app is network based, generally making 4 calls concurrently on each view controller and every two minutes of being on the same VC I'll make the calls again. The calls are in an operationQueue and I do call cancelALLOperations where appropriate. In between the calls we update using sockets, to which we have our own implementation.

A VC can use imageWitUrl: for up to 20 images simultaneously. These are thumbnail sized images.

My Questions,

  1. Has anyone dealt with smiler stack trace. Would you know reproducible steps to cause it?
  2. I can't see from the commits, but would anyone know if its been resolved in latest version or in 2.0?
  3. Do you think it could just be how I implement afnetowrking in my code?

I understand this isn't best question, especially as I'm so out of date but as the project has a large release cycle and I've no way to reproduce it I'd like advise of my peers.

I've found a closed issue on this but it doesn't mention a fix, https://github.com/AFNetworking/AFNetworking/issues/1574

All the calls are AFJSONRequestOperation's, example of my standard call.

AFJSONRequestOperation *requestOperation   = [AFJSONRequestOperation JSONRequestOperationWithRequest:request success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON) {
    // create our models and pass it back
    NSArray *results = [self parseBaseEventsWithDictionary:JSON andSort:NO];
    success (results);
} failure:^(NSURLRequest *request, NSHTTPURLResponse *response, NSError *error, id JSON) {
     failure(error, response.statusCode, @"failure", JSON);
}];

return requestOperation;

The exception

SIGSEGV
SomeName -[AFHTTPRequestOperation error]

The Stack Trace off the Testflight report I keep getting:

0 SomeName 0x0022fdea testflight_backtrace

1 SomeName 0x0022f47e TFSignalHandler

2 libsystem_platform.dylib 0x38878062 _sigtramp

3 SomeName 0x0020d172 -[AFHTTPRequestOperation error]

4 SomeName 0x0020eb46 __65-[AFImageRequestOperation setCompletionBlockWithSuccess:failure:]_block_invoke_2

5 libdispatch.dylib 0x38738d1a _dispatch_call_block_and_release

6 libdispatch.dylib 0x3873e68e _dispatch_async_redirect_invoke$VARIANT$mp

7 libdispatch.dylib 0x3873fd70 _dispatch_root_queue_drain

8 libdispatch.dylib 0x3873ff58 _dispatch_worker_thread2

9 libsystem_pthread.dylib 0x3887adbe _pthread_wqthread

10 libsystem_pthread.dylib 0x3887ac83 start_wqthread

1
What is the actual error/exception?trojanfoe
Thanks for pointing that out just updated the question, it's a SIGSEGV in [AFHTTPRequestOperation error].BooRanger
OK, so what does this block/method do with error? failure(error, response.statusCode, @"failure", JSON);trojanfoe
In general we show a popover depending on the responseStatusCode.BooRanger
Sorry further looking shows that error.localizedDescription is passed to the popover. It would also be logged with TFLog on to testflight, on this crash I doesn't get logged.BooRanger

1 Answers

1
votes

Has anyone dealt with smiler stack trace. Would you know reproducible steps to cause it?

I can't see from the commits, but would anyone know if its been resolved in latest version or in 2.0?

I can't find the exact issue, but I have a pretty strong recollection that this was fixed way before 2.0 was released (and way after 1.1.0.)

Do you think it could just be how I implement AFNetworking in my code?

I don't think so, unless you modified the library directly. An NSError object is created, stored, and passed back in the completion handler. Nothing too complex.

In summary: I would assume updating to 1.3.3 fixed this, unless you find information to the contrary.