[wayland] Animated webp image leaking memory

[lundmar]

Environment: flutter-elinux v3.24.3, Yocto Kirkstone, NXP iMX8/ARM64, wayland.

We see memory leaking when running the following simple test application which features a 100 x 100 pixel webp image:

import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: Text("Animated WebP Test")),
        body: Center(
          child: Image.asset("assets/images/minion100x100.webp"), // Leaking
          // child: Image.asset("assets/images/minion500x500.webp"), // Not leaking
        ),
      ),
    );
  }
}

Memory/CPU usage when running the test application for 3 hours:

Memory usage keeps growing at a rate of about 3MB/hour.

Switching to another 500x500 pixel webp image does not leak:

Both image files have passed the 'webpinfo' tool without any errors/warnings.

The image files are available here: https://github.com/lundmar/test-images

This issue seems to be specific to flutter-elinux since running the same application using desktop flutter in a flutter-3.24.4/Ubuntu-24.10/wayland environment does not leak.

We've been using valgrind to try identify the memory leak but valgrind seems to get confused by the dart VM and the few memory sizes that are reported definitely/indirectly/possibly lost stays the same over time, only "still reachable" memory changes but nowhere near the leak size we see for the application process. Attached are the valgrind logs for short (1-5 minute) and long (1 hour 30 minutes) runs for both test cases. There are some webp decode related functions mentioned in the still reachable loss records but it seems to give the same picture for both the leaking and not leaking test case.

100x100-valgrind-1h30m.log 100x100-valgrind-1m.log 500x500-valgrind-1h30m.log 500x500-valgrind-5m.log

[HidenoriMatsubayashi]

Probably this is the same issue as #274.

[lundmar]

Probably this is the same issue as #274.

Maybe. Would it be possible for you to try run the test application on your flutter elinux setup to see if you can replicate?

If it is a GC issue it is definitely not recovering over time - here is a 9 hours test run:

I'm not sure what to conclude from the rising CPU usage.

[lundmar]

I let the leaking image test application run and we get this cpu/mem usage:

After 43 hours the screen froze and the target had crashed in a way so I could not access it and I had to recycle it to login again. Unfortunately we do not have persistent journal log enabled so any application crash information is lost. I'll enable persistent logging and repeat the test in hope to get something useful from the logs that may help tell us what is going on.