Memory leak on flutter web when using Icon in ListView #122189
Comments
IvoB1987
added
the
from: performance template
|
By the way I also posted it on stackoverflow: https://stackoverflow.com/questions/75674384/memory-leak-on-flutter-web-when-using-icon-in-listview |
darshankawar
removed
the
from: performance template
Triage reportI can reproduce this issue with Code Sample (Same as OP)import 'package:flutter/material.dart';
void main() {
runApp(const MaterialApp(
home: Scaffold(body: MemoryTest()),
));
}
class MemoryTest extends StatelessWidget {
const MemoryTest({super.key});
@override
Widget build(BuildContext context) {
return ListView.builder(
itemCount: 500,
itemBuilder: (context, index) => const Icon(Icons.circle)
);
}
}Screenshot of heap snapshots using Chrome devtools
|
exaby73
added
engine
|
This issue feels a bit related to my issue, so for now I'm posting my initial comments here. If it later proves to not be related to this issue, I will open a separate issue. I have also been tracking a troublesome bug in a rather big Flutter WEB build as well. It feels like the app gets more sluggish as it runs and eventually crashes with an issue on "MaterialIcons", shown below:
I see this on both Flutter 3.7.7 and latest 3.9 master. I only see it in WEB release build, not in WEB debug mode builds. Also in VM builds, like macOS, I see no issues at all, there are no console log message at all that could provide a hint about what might be wrong. Since I only get the crash on a web release build, I'm finding it very difficult to debug it and provide any useful info. Also time to crash is a bit random, but not very long. I also see other strange behavior in the release mode build of same app, with values changes in hover over items, that do have a hover response, but in the particular use case should not change on hover and does not do so on other builds, except on WEB release mode builds, again WEB debug build does not show that issue either. I feel something important is being optimized out by the WEB release mode to JS compiler that should not be. This would not be the first time I have experienced this type of bug, this has the exact same "smell" the other dart2js (now dart compile js) one I experienced some years ago. The web crash above says "Build with -sASSERTIONS" for more info. How do I do that in Flutter? I see in docs that "dart compile js" has a "--enable-asserts" flag, sounds like it, but it did not work with flutter run, like in: At the moment I don't know how to dig deeper into this issue to provide any more helpful info on the issue. I can only see that it seems like a quite bad Dart web compiler bug. Perhaps this issue belongs in the Dart repo? Maybe there is a report about it already. I will god have a look and see if I can find something related to this there as well. |
|
@rydmike it could be related yeah. My application also starts to throw the same errors when the memory runs up too high. Maybe that's also happening with your application. |
|
@IvoB1987 I think it is related as well. As mentioned I also see other flaky behavior on the release mode WEB build. Do you get the memory leak in debug mode WEB builds? I did not see my issue there, but I will look again and do more tests and investigations into the issue. |
|
@rydmike it also happens in debug for me |
|
@rydmike I did some more testing and while it's true it happens both on debug as release for me it seems it does happen much faster on release. On release the memory raises faster and therefore the crashing happens earlier. And yeah I have very similar stack traces as you. |
|
I've tried downgrading to Flutter version 3.3.10. The issue doesn't seem to be there, so it must have been introduced in 3.7.0 |
|
@IvoB1987 I could try that downgrade as well, just to check, but I need to disable a significant amount of features in the app where I am observing suspected similar issues. Since the app is specifically geared towards using all new M3 features that did not exist in Flutter 3.3.10, so a bit tricky, but doable, I just need to comment a lot of code to do it. I did however not experience the issues I see now on Web builds with Flutter 3.3 either, minus the new M3 widgets now used, that imo have nothing to do with this issue anyway. I tried looking around in the DartLang repo for anything that might look related, but saw nothing immediately that stuck out in the 'area-web' tagged issues as related to this issue: https://github.com/dart-lang/sdk/labels/area-web?page=2&q=is%3Aopen+label%3Aarea-web
EDIT: Also thanks for the abvoe additional info, I will look closer at my debug build as well. |
|
Bisected the The |
|
Thanks @jason-simmons for that info and for starting looking into this. I was now able to get a slightly different crash stack trace error on a WEB release mode build on same app as before, but with very similar details as before. This time the issue says font was "NotoSans_regular", which I use via GoogleFonts, but the primitives it crashes on looks identical as before:
All I did in the app was pretty much toggle it between light/dark mode until it gave up. Again I was unable to get this crash in WEB debug mode, or any mode at all with VM builds, JIT or AOT. |
|
@jason-simmons another very peculiar thing I can see in the same app, and only in its WEB release build, is that when I hover over the theme colored box below, somehow the values and names are changing, which in code would/should only happen if the shown colors are changing, and I do believe they are doing so but only very slightly and the boxes are just doing what they are supposed to do in that case. I want to stress that this should not be happening in this app in this mouse hover over the boxes, and that it does NOT do so in any other build, except in WEB release mode. I have no idea what is going in this WEB release build with this issue, as it is not happening in any other build and there is no way for me to debug it or even know how I would reproduce it. Maybe its root cause is the same as the issue we are looking at now, or maybe it is a different issue, but it did not exists before Flutter 3.7 either. (The corresponding tonal palette tone, being highlighted on hover above the theme colors, is intentionally, that is what it should be doing). Screen.Recording.2023-03-09.at.22.36.28.mov |
|
Got a yet another crash with web release mode using the same app. This one is a bit different. Again there are no issues in VM debug/release builds, and I have not yet gotten the app to crash in web debug mode builds, but I will keep trying.
Crash details example |
|
Looked at Flutter Web's behavior in the original example in #122189 (comment) The primary issue here is that CanvasKit's paragraph binding is creating a new SkParagraph In
On Web, the However, for variable fonts SkParagraph needs to call But with no cache So every new paragraph layout creates more typeface instances and cache entries, resulting in a leak. |
|
Thanks @jason-simmons for this finding and info. I tested building the above same app that uses custom fonts, lots of icons, and yes it has a lot of text as well, with the html renderer only in release mode. I could not get it to crash anymore. I tortured it for quite a while doing things that consistently quite quickly crashes the canvaskit build. It did not crash. Normally the the html renderer is more sluggish, but with this canvaskit bug effective, it actually felt more snappy than the canvaskit build. The html render has other issues with poorer flutter_svg support and fuzzy scaled fonts, making it a not viable option for this app. I could still see the numbers in the colored boxes (as shown and described above earlier) randomly changing values in the html release build as well. As before I cannot observe that behavior, that should not be there, on any VM build, debug/release, or even web debug buildd, be it canvaskit or html. That issue is only present on web release builds, and with both html and canvaskit renderer. Thus I still suspect the web release mode complier optimizes out something that breaks the correct and expected functionality. I just noticed that there is a certain combination of other views/elements that must be present on the same screen for this issue to present itself on the web release mode builds. I will investigate that further. It looks like this is a separate issue, so I will open another case for it when/if I am able to isolate it better. |
|
@jason-simmons That's amazing digging! We also have this issue - #120921 - where our paragraph caching strategy is ineffective in the material demo app. But perhaps we don't need any engine-side caching at all if we can fix this font collection issue, and rely on a combination of the recently added |
|
SkParagraph has the ability to cache paragraph layouts. But that cache is kept within the So Flutter Web is not getting the benefits of SkParagraph's paragraph cache because it recreates the |
|
@yjbanov I also noticed the severely degraded performance on release mode skia builds, after 3.7 release I think, it could also have arrived with one of the 3.7 hotfixes, not sure. Yes it can be seen on theme transitions in general, not just light/dark, but easier to observe on it. I also see it on tooltips, their show animation have gotten quite poor. I also noticed that the mentioned official Material 3 demo app contains what might be considered to be an unusual amount of I started down the same road in the Theme Playground v7 app, but quickly noticed it did not help and besides they were not needed at all before Flutter 3.7, performance was quite OK. Same issues observed in Themes Playground as in Material 3 demoAs a perhaps interesting side note, the FlexColorScheme package companion app ThemesPlayground, where I noticed all these, embeds a slightly modified version of the official Material 3 demo app. The demo app can be shown in various devices and it gets its theme from the FlexColorScheme package in that is configured by Themes Playground app. So all widgets in it can completely change style via in-app dynamic theming from its parent. It is used to show how different theme settings impacts the look of Material widgets. It looks like this: I do see the same issues also when not using pages that contain the Material 3 demo app put into into a DeviceFrame, inside the Themes Playground. So I certainly knew it was not the cause. The Themes Playground does all the things the Material 3 demo app does as well, and much more. Plus it contains a lot of text icons, much more than the Material 3 demo, and it uses custom in-app dynamic theming of almost all available Material component themes. It's a good torture test of almost all Flutter theming features and changing them in realtime inside the app. Additionally it's all inherited by a number of simple theme showcase apps, the Material 3 demo being one of them, plus it writes the FlexColorScheme API config code for the theme shown as the theme id modified interactively with UI controls. Not just performance, larger SKIA web builds just crashes after a whileWhy mentioned all this? Well I'm currently unable to release the new version of the FlexColorScheme package and the Themes Playground app due to this issue. Suffice to say, it all works and runs buttery smooth on macOS and Windows desktop builds, or Android/iOS device as well. Currently the app actually performs better as a html build on desktop, a first, never seen that before. Skia is very bad now, and it crashes pretty quickly. HTML build has other issues, with fuzzy scaling and svgs being a bit so so, it is not fast either, but currently faster than SKIA with Flutter stable 3.7.7, and of course it does not crash after using it for about 1 minute. More info about Themes PlaygroundIf of interest, more images and videos can be found of the new Themes Playground app e.g. in these tweets: How it started: https://twitter.com/RydMike/status/1625212853740249100?s=20 And more: https://twitter.com/RydMike/status/1635684469284667392?s=20 |
|
Just as info, I just tried going back to stable 3.7.0 and building the Themes Playground app on it as well. This same bug exists already then, so it did not sneak in via any later hotfix. I did not really think so, but I just wanted to make sure. BTW, gosh is it slow in release mode with canvaskit, it really struggles with all the text and screen resizes. Ironically, the html renderer release mode build is now much faster and smoother (never seen that before this issue) and it does not crash. However, it draws some parts of the app really soft and fuzzy looking (scaled content, and normal UI sometimes too after a zoom transition), well to a critical eye at least. That has always been a "feature" of the html render, which is why I prefer to not use it. However, as long as this bug is in effect on stable channel, that will have to be the temporary workaround. |
Bug: flutter/flutter#122189 Change-Id: I7d951a676e11a1c9f4859daa744d280b56fb6d5c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/657270 Reviewed-by: Kevin Lubick <kjlubick@google.com>
|
Generally I do test with master as well, and follow what is happening there, mostly for theming and M3, but I have not tried a build of this particular app that recently on master, latest was a few days ago. I will try it later today, thx for the heads up 💙 |
What I should have said is that our benchmarks only caught it on Friday. The new build has been available for longer than that. I'm suspecting we have more than one regressions. We'll look into this this coming week. |
|
Just made a test release build using Tortured the app for a while, with theme and font changes, and complex layouts, lasted longer than before, but eventually, well eventually is maybe a bit strong, maybe I played with it for 2 minutes, until it bombed when just changing between light/dark theme:
I think it used to bomb faster before, but not sure, it was always a bit random and varying feeling. I will start timing it in future tests. Feels like it depends on how much and fast (often) you torture it, with theme and text changes. Chrome console traceAs before, runs fine, stable and fast in any mode on VM builds, also stable in html renderer release web build. I would even say html release still feels snappier than above canvaskit did, but I will test them more side by side, and do some profiling too with both later. |
|
Tested above canvaskit build again with |
|
Fixed with flutter/engine#40740 |
|
@hterkelsen can we expect to see a hotfix on stable? |
|
Our beta 3 cut is scheduled happen shortly, which will become a candidate for the 3.10 stable release. If all goes well, it will include this fix. We won't be able to hotfix this into 3.9 as there's too many changes across Skia and Flutter. |
|
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-triage-bot
bot
added
P0
Details
Consider this simple full application:
When running on web the memory keeps increasing indefinitely while scrolling through the list, as can seen in the Task Manager of Windows. Is this a bug in Flutter or how can I rewrite this code to prevent the memory leak? Simply replacing the
Iconwith aTextdoes not cause a leak.Target Platform: web
Target OS version/browser: Chrome Version 110.0.5481.180 (Official Build) (64-bit)
Devices: Windows 10
Logs
Logs
The text was updated successfully, but these errors were encountered: