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

App crashes when backgrounded and brought to foreground #18

Open
seanperez29 opened this issue Nov 27, 2024 · 11 comments
Open

App crashes when backgrounded and brought to foreground #18

seanperez29 opened this issue Nov 27, 2024 · 11 comments

Comments

@seanperez29
Copy link

I am running analytics-swift version 1.7.1 and analytics-swift-live version 3.1.1 and upon launch of the app I am seeing this in the Xcode debugger:
Screenshot 2024-11-27 at 11 17 40 AM

And then if I background our app and bring it to the foreground 1-2 times you get more logs and then it will end up crashing:

Screenshot 2024-11-27 at 11 18 31 AM

If I run analytics-swift version 1.7.1 with analytics-swift-live version 3.1.0 I do not experience any of the debugger logs or the crash, everything seems to work as expected. But once I updated to version 3.1.1 that's when this all started.

I am on Xcode version 15.4

@seanperez29 seanperez29 changed the title Assertion failure when app backgrounded and brought to foreground App crashes when backgrounded and brought to foreground Nov 27, 2024
@Ferdzz
Copy link

Ferdzz commented Nov 27, 2024

We are experiencing this crash as well on 3.1.1. 100% reproduction rate when backgrounding and foregrounding the app

@sadaf-behbahani
Copy link

sadaf-behbahani commented Nov 27, 2024

Hi @bsneed and team,

We’ve transitioned to Analytics-Swift-Live 3.1.1 as instructed following the deprecation of analytics-swift-filters. Unfortunately, this new solution is causing crashes in our application, making it impossible to create a deliverable. This has become a critical blocking issue for us.

The lack of stability in the provided solution has already led to a significant loss of time and resources for our team. The prior removal of released versions disrupted our CI pipelines, and now the recommended alternative is introducing additional complexity and delays.

We urgently need:

  • A rapid and efficient fix for the crashes caused by Analytics-Swift-Live.
  • Clear and precise guidance on how to resolve these issues without further disruptions to our delivery process.
  • Assurance that this replacement library will be stable and properly supported moving forward.

We appreciate your understanding of the urgency here and hope for a swift resolution. Please let us know how we can assist in diagnosing or reproducing the issue to expedite the fix.

Looking forward to your prompt response.

Best regards,
Sadaf

@bsneed
Copy link
Contributor

bsneed commented Nov 27, 2024

Thanks @seanperez29 for the report, looking into this now.

@bsneed
Copy link
Contributor

bsneed commented Nov 27, 2024

Can anyone here share how they're doing their analytics setup? Something akin to this:

image

It'd also be useful to know where this is happening in your app, ie: appDidFinishLaunching, etc.

@Ferdzz
Copy link

Ferdzz commented Nov 27, 2024

SwiftUI, on our App's init(). Not called again on background/foreground cycle.

    let configuration = Configuration(writeKey: writeKey)
      .flushInterval(10)
      .trackApplicationLifecycleEvents(true)

    let analytics = Analytics(configuration: configuration)
    let brazeDestination = BrazeDestination(additionalConfiguration: { configuration in
      // Some minimal Braze configuration
    }, additionalSetup: { braze in
      // Additional Braze setup for InAppMessages
    })
    analytics.add(plugin: brazeDestination)
    analytics.add(plugin: DestinationFilters())
    return analytics

@seanperez29
Copy link
Author

This is our full setup and it's happening in didFinishLaunchingWithOptions

Screenshot 2024-11-27 at 2 27 28 PM

@bsneed
Copy link
Contributor

bsneed commented Nov 27, 2024

Thanks everyone!

I was finally able to repro in a test case.

@PhilippeTouchTunes
Copy link

Thanks @bsneed for your help !
Could I ask you if you have an idea of how long it would take you to provide a new version with a fix to this crash ?
We are currently in the process of creating new builds of our app and we can not deliver a build with this crash in it.

@bsneed
Copy link
Contributor

bsneed commented Nov 27, 2024

I don't know yet. I'm only working on this at the moment and not stopping till it's fixed.

@bsneed
Copy link
Contributor

bsneed commented Nov 27, 2024

I've narrowed down the issue. Whenever the js engine shuts down, there's still some outstanding objects (specifically the Destination Filter) that get released after the engine. The assert in the engine is reporting that the destfilter hasn't been let go yet, though it eventually is. The reason this manifests at background/foreground is because foreground kicks off a re-fetch of settings, which tears down the JS engine and re-builds it so it can use any new settings data.

I'm considering just removing the assert for now since there's no actual leak, just an assert causing an unnecessary crash. I figure this will get everyone moving again while I continue to look at how to refactor such that deallocs are more in sync with the js engine.

Thoughts? If I don't hear back in 15/20 mins, I'll go ahead and publish a new version with this change and leave this bug open in the meantime.

@bsneed
Copy link
Contributor

bsneed commented Nov 27, 2024

This crash has been mitigated by #19. Please see 3.1.2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants