Network failure in authentication treated as success, leading to null dereference

[mdpye]

See http://crashes.to/s/c83e37cf8ad

From my (naive) reading, connection:didFailWithError was called (frame 6), but no error object was passed, so the connectionError is assigned a null value. When calling finish (frame 5) the success branch is chosen, because it detects previous failure by testing connectionError, assuming that if it has been assigned it will have been assigned something non-null.

[lukeredpath]

@mdpye looks like you might be right. Do you know what circumstances could have caused didFailWithError: to be called with a nil error? Perhaps PTURLRequestOperation should use a boolean flag to indicate failure rather than relying on the presence of an actual error - that should solve this issue.

Do you see this error a lot?

[mdpye]

I'm afraid I don't know much about the circumstances - I'm working at Pusher, so I'm filing the report on behalf of someone who got in touch with support, don't have much visibility over their server logs for the period.

[lukeredpath]

OK, let me know if something similar comes up. I'll try and get a fix for this in the next release.

[mdpye]

Great, thank you.

[adrianioancozma]

Hi there, I have encountered the same issue, app crash in libPusher w/ the same stack trace, w/ the same err message, when working w/ a server that uses to cough HTTP500 & binaries in JSONs from time to time.
For some unknown reasons, it appears more frequently on the release environment.
I've used a rapid fix which seems to be working in out tests:

PTPusherChannelAuthorizationOperation.m:71

- authorizationData = [[PTJSON JSONParser] objectFromJSONData:responseData];
+ authorizationData = (responseData==nil) ? nil : [[PTJSON JSONParser] objectFromJSONData:responseData];

[hamchapman]

@lukeredpath is the fix above fine to be added to the library?