Repository navigation
Framework shouldn't send invalid matrix to engine #31700
Description
See #31650 (comment) for where we got an invalid matrix, and #31650 (comment) for how to reproduce it.
See #31650 (comment) for where we got an invalid matrix, and #31650 (comment) for how to reproduce it.
Activity
liyuqian commentedon Apr 26, 2019
While running #31650 (comment) with #31701 and
FlutterError.onError = (FlutterErrorDetails details, { bool forceReport = false }) => FlutterError.dumpErrorToConsole(details, forceReport: true);, we have:liyuqian commentedon Apr 26, 2019
CC @tvolkert @xster
xster commentedon Apr 26, 2019
As I mentioned in the engine chat thread, discussed offline with @Hixie. Given our current patterns, this is more or less a design choice and given that, it's an 'intended behavior'.
Once we hit a un-layout-able render object during layout, the framework already failed and all bets are off. We're choosing to let it limp on because we want to not crash to allow hot reload and because sometimes, trying to paint even without a layout might work. But most of the time, what we end up trying to paint is likely non-sensical and downstream APIs will need to degrade gracefully as much as possible.
liyuqian commentedon Apr 26, 2019
@xster For the engine our current solution is
FML_CHECKwhich will terminate the app. Is there a way for the framework to elegantly fall back to some simple matrix (say identity) instead of sending an invalid one?xster commentedon Apr 27, 2019
We can, though for consistency with every other canvas/layer/etc APIs which may all be invoked with non-sensical values, it still might not help you avoid needing to let all 'dart:ui' APIs be resilient to invalid input.
liyuqian commentedon Apr 27, 2019
@xster : right, I think we need to be resilient in multiple levels. In the lowest engine level, the solution might be too brutal (e.g., terminate the app without useful stack trace information of the framework). Catching it in the framework seems to be a little more helpful.
For this specific stack trace and crash app, do you think that we need to add anything in the framework? I guess this may also depend on what the purpose of @tvolkert 's crash app is. I'm not familiar with the stack trace or the crash app, so I'll leave the final decision between you and Todd :)
Add more asserts to check matrix validity (#31701)
github-actions commentedon Aug 29, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.