Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash in stopFlow(immediately immediately: Bool = false, userDidSkip skipped: Bool = false, shouldCallDelegate: Bool = true ) #90

Closed
swetaarya opened this issue Jan 6, 2017 · 15 comments
Labels

Comments

@swetaarya
Copy link

0 libswiftCore.dylib 0x100fb04ac hidden#8277 (_hidden#7745:75)
1 libswiftCore.dylib 0x100fbe3fc swift_unknownUnownedTakeStrong (_hidden#9593:764)
2 Instructions 0x100b1acc8 FlowManager.(stopFlow(immediately : Bool, userDidSkip : Bool, shouldCallDelegate : Bool) -> ()).(closure #2) + 412
3 UIKit 0x1969c9cf8 -[UIViewAnimationBlockDelegate _didEndBlockAnimation:finished:context:] + 492
4 UIKit 0x1969c981c -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 312
5 UIKit 0x1969c965c -[UIViewAnimationState animationDidStop:finished:] + 160
6 QuartzCore 0x193e4a180 CA::Layer::run_animation_callbacks(void*) + 260
7 libdispatch.dylib 0x18f9c11c0 _dispatch_client_callout + 16
8 libdispatch.dylib 0x18f9c5d6c _dispatch_main_queue_callback_4CF + 1000
9 CoreFoundation 0x190ae3f2c CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 12
10 CoreFoundation 0x190ae1b18 __CFRunLoopRun + 1660
11 CoreFoundation 0x190a10048 CFRunLoopRunSpecific + 444
12 GraphicsServices 0x192496198 GSEventRunModal + 180
13 UIKit 0x1969fc2fc -[UIApplication _run] + 684
14 UIKit 0x1969f7034 UIApplicationMain + 208
15 Shop101 0x1003fdafc main (AppDelegate.swift:31)
16 libdispatch.dylib 0x18f9f45b8 (Missing)

@swetaarya
Copy link
Author

Could u please tell me, what is happening here.

@ephread
Copy link
Owner

ephread commented Jan 13, 2017

Hello @swetaarya, sadly from such stack trace, without more context attached to it, I'm afraid I can't really tell you issue right away. What action lead the crash?

@ephread ephread added the bug label Jan 13, 2017
@swetaarya
Copy link
Author

i think FlowManager.(stopFlow(immediately : Bool, userDidSkip : Bool, shouldCallDelegate : Bool) -> ()).(closure #2) + 412 causing crash

@swetaarya
Copy link
Author

i was calling CoachMarkController.startOn(self) in viewDidLoad() method. May be this causing problem

@ephread
Copy link
Owner

ephread commented Jan 13, 2017

That's extremely likely, you need to call startOn from viewDidAppear, as the view hierarchy needs to be ready. ;)

@swetaarya
Copy link
Author

But why crash occuring in FlowManager.(stopFlow(immediately : Bool, userDidSkip : Bool, shouldCallDelegate : Bool) -> ()).(closure #2) + 412

@ephread
Copy link
Owner

ephread commented Jan 13, 2017

Certainly because of a nil pointer inside stopFlow, either self or self.coachMarksViewController (see here). This stack trace seems to indicate that the parent object was somehow deallocated and the closure lived its short and unhappy life by itself. But again, without more context (some of the code you're using, or which action lead to the crash) I can't be of any more help.

@anfriis
Copy link

anfriis commented Feb 28, 2017

I just had this crash in my app too.
I think I was quickly closing and opening some view controllers, and calling stop(immediately: true) when closing a view controller.

instructions crash

When looking into the coachMarksViewController property in the FlowManager, I can see that it is marked as unowned. I looked in the Apple documentation for unowned and it says

If you try to access the value of an unowned reference after that instance has been deallocated, you’ll get a runtime error.

So I suspect that the coachMarksViewController was deallocated and maybe we should consider making it weak and optional instead, so we can avoid the crash?

anfriis added a commit to anfriis/Instructions that referenced this issue Feb 28, 2017
@anfriis
Copy link

anfriis commented Feb 28, 2017

PR: #99

@anfriis
Copy link

anfriis commented Mar 6, 2017

I seems to be working in the PR I created, so can it be merged to master?

@ephread
Copy link
Owner

ephread commented Mar 6, 2017

Thanks for the work @anfriis, I haven't merged your PR yet, because I believe that the block shouldn't normally outlive the controller (hence the use of unowned). I wanted to investigate beforehand. ;)

@anfriis
Copy link

anfriis commented Mar 6, 2017

No problem :) but i guess the block is outliving the controller because the controller gets deallocated when the containing view controller does, and then the block lives on somehow

@anfriis
Copy link

anfriis commented Mar 6, 2017

I can see that I now have a new problem, that the instructionsRootView is not removed from the app window, if the coachMarksViewController is nil when calling detachFromParentViewController(), so the instructions view is shown on the new page... So it would be great if you can investigate it :)

@halolee
Copy link
Contributor

halolee commented Apr 30, 2018

I could replicate the same issue by quickly opening and closing ViewControllers.

Based on the stack trace, the crash line points to FlowManager:126 self.coachMarksViewController.detachFromWindow(), which is an indication of using a deallocated self reference.

Further on @anfriis comment, I would propose to keep a weak self reference in the completionBlock instead of touching the unowned reference.

will submit a pull request shortly after.

        let completionBlock = { [weak self] (finished: Bool) -> Void in
            guard let strongSelf = self else { return }
            strongSelf.coachMarksViewController.detachFromWindow()
            if shouldCallDelegate { strongSelf.delegate?.didEndShowingBySkipping(skipped) }
        }

halolee added a commit to halolee/Instructions that referenced this issue May 1, 2018
ephread added a commit that referenced this issue May 27, 2018
@ephread
Copy link
Owner

ephread commented May 29, 2018

It seems #161 fixes the issue.

@anfriis and @halolee, thanks a lot for working on this and fixing the issue!
I'm now going to close #99 that I left dangling for too long instead of investigating the issue 😓.

@ephread ephread closed this as completed May 29, 2018
Tonbouy pushed a commit to Tonbouy/Instructions that referenced this issue Nov 29, 2019
Tonbouy pushed a commit to Tonbouy/Instructions that referenced this issue Nov 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants