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

LottieLogger.assertFailure should not crash in Release build. #1663

Closed
blastmann opened this issue Jul 26, 2022 · 7 comments · Fixed by #1665
Closed

LottieLogger.assertFailure should not crash in Release build. #1663

blastmann opened this issue Jul 26, 2022 · 7 comments · Fixed by #1665
Labels

Comments

@blastmann
Copy link

blastmann commented Jul 26, 2022

Which Version of Lottie are you using?

Lottie 3.3.0

Expected Behavior

LottieLogger.shared().assertFailure should not trigger in Release build. Assertion should be filtered.

Actual Behavior

It crashes when assertFailure happened. Did not work as expected.

Demo

latest.zip

@calda
Copy link
Member

calda commented Jul 26, 2022

LottieLogger.shared.assertionFailure defaults to the built-in stdlib assertionFailure function, which does not terminate the process in release builds:

This function’s effect varies depending on the build flag used:

  • In playgrounds and -Onone builds (the default for Xcode’s Debug configuration), stop program execution in a debuggable state after printing message.
  • In -O (release) builds, has no effect.

Is your release build using -Onone? If not, but you're still experiencing a crash in release builds, could you share a sample project that reproduces the issue?

You can always customize the behavior of LottieLogger.shared to suit the needs of your project. For example you could have it always just log to the console instead of calling assertionFailure by setting LottieLogger.shared = .printToConsole.

@calda calda closed this as completed Jul 26, 2022
@calda calda reopened this Jul 26, 2022
@calda
Copy link
Member

calda commented Jul 26, 2022

Ah I just noticed that you had attached a sample project. Thanks!

This does seem unexpected -- I don't understand why it crashes when you call LottieLogger.shared.assertionFailure but not Swift.assertionFailure, considering the Lottie logger assertion implementation literally is Swift.assertionFailure:

assertionFailure: @escaping AssertionFailure = Swift.assertionFailure,

if I change the LottieLogger init to instead be:

assertionFailure: @escaping AssertionFailure = { message, file, line in 
  Swift.assertionFailure(message(), file: file, line: line) 
},

then the crash goes away. This seems pretty bizarre.

@calda
Copy link
Member

calda commented Jul 26, 2022

Haha wow ok, this is weird for sure. LottieLogger.shared.assertionFailure crashes in release but LottieLogger().assertionFailure doesn't. I'll make the change above on master to workaround this issue, thank you for the report!

@calda calda added the bug label Jul 26, 2022
@calda
Copy link
Member

calda commented Jul 26, 2022

I filed a compiler bug for this, since it seems unexpected: swiftlang/swift#60249

@blastmann
Copy link
Author

Thank you so much!

@calda
Copy link
Member

calda commented Jul 27, 2022

This is fixed in today's 3.4.1 release by the way 👍🏻

@chaoxcheng
Copy link

chaoxcheng commented Jun 15, 2023

This is fixed in today's 3.4.1 release by the way 👍🏻

this bug not fixed in 4.2.0 release when I use:
´
func position(for keyPath: String) -> CGPoint {
let kp = AnimationKeypath(sgKeypath: "(keyPath).Transform.Position")
guard let vector = getValue(for: kp, atFrame: nil) as? LottieVector3D else {
return CGPoint.zero
}
return CGPoint(x: vector.sizeValue.width, y: vector.sizeValue.height)
}
´
image
image

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