Crash reported by Crashlytics on iOS 9

[gathan]

Hello, this is a weird crash getting reported from Crashlytics. I have also experienced this on my own using the app and getting reported this issue afterwards. As you can see from the stack, it happens when the progress hud is getting removed.

Unfortunately, i have not found a way to reproduce this issue while a debugger is attached, and it is very difficult to understand if I can make a fix to muzzle it.

anyway,

Is there any way you can fix it or give me a hint of what is wrong? Thanks

Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000010
 raw
0   libobjc.A.dylib 
objc_msgSend + 16
1
UIKit   
__UIViewWasRemovedFromSuperview + 248
2   UIKit   
-[UIView(Hierarchy) removeFromSuperview] + 424
3
Pockee  
MBProgressHUD.m line 365
-[MBProgressHUD done]
4   UIKit   
-[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 312
5
UIKit   
-[UIViewAnimationState animationDidStop:finished:] + 108
6
QuartzCore  
CA::Layer::run_animation_callbacks(void*) + 284
7
libdispatch.dylib   
_dispatch_client_callout + 16
8
libdispatch.dylib   
_dispatch_main_queue_callback_4CF + 1844
9
CoreFoundation  
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
10
CoreFoundation  
__CFRunLoopRun + 1628
11
CoreFoundation  
CFRunLoopRunSpecific + 384
12
GraphicsServices    
GSEventRunModal + 180
13  UIKit   
UIApplicationMain + 204
14
Pockee  
main.m line 15
main
15
libdyld.dylib   
start + 4

[matej]

Can you clean up the pasted stack trace? Use the "insert code" to make it more readable.

Hm.. Looks this could be a memory management issue. UIViewWasRemovedFromSuperview sends a message to 0x0000000000000010 (nil + offset?). Looks like that private function potentially messages a ton of objects. Could be hard to track down. Are you using ARC?

Since I haven't seen something like this being reported before, it's more likely that it's an issue somewhere else in your app and MBProgressHUD is just triggering it. I'm not sure though.

[gathan]

Hello! thanks for the reply.

I am using ARC. I cannot be sure, But it think there must be something wrong with KVO/KVC and strong/weak references. It seems that 'done' method is triggered by delegation from KVO (animationDidStop:finished), to an object that is already deallocated from ARC. There might be a missing __strong reference within a block or something...

Thanks again

[matej]

The latest version no longer uses KVO and has some other substantial changes. You might want to give that a try once it is ready (subscribe to https://github.com/jdg/MBProgressHUD/issues/334).

[gathan]

Great! Thanks for the instant response!

[teffi]

I'm using the latest version but am having the same issue. Crash logs are totally identical to the one posted. Weird though that this happens intermittently. Not all of my users are experiencing the crash.

Update: I can't still replicate the crash on my end however after checking, I think the implementation on [MBProgressHUD done] method is not block proof. In my case, MBProgressHUD display is handled by a request class(RequestModel.m) which calls MBProgress on success and failure completion block. At this point, the view that was set for MBProgressHUD can potentially be nil anytime.

A possible solution to avoid the crash is to check if superview is still valid before proceeding to removeFromSuperview.

if(self.superview != nil){
    [self removeFromSuperview];
}

I will try to rollout this fix to my app and see if it addresses the issue.