PdfViewer memory leaks when when widget is unmounted during rendering

[espresso3389]

The discussion is for PR #220 that insists potential memory leaks when unmounting PdfViewer widget.

[espresso3389]

@jezell
I've created simple example code to test multiple PdfViewer instances running concurrently and changing pages randomly. It runs without any notable problems on Desktop and Web.

Do I miss something important to see the actual memory leaks?

import 'dart:math';

import 'package:flutter/material.dart';
import 'package:pdfrx/pdfrx.dart';

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

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home: const PdfrxAsyncDispose(),
    );
  }
}

class PdfrxAsyncDispose extends StatelessWidget {
  const PdfrxAsyncDispose({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        backgroundColor: Theme.of(context).colorScheme.inversePrimary,
      ),
      body: ListView.builder(
        itemCount: 100,
        itemBuilder: (context, index) => Container(
          margin: const EdgeInsets.all(1),
          height: 320,
          child: PdfViewer.asset('assets/PDF32000_2008.pdf',
            params: PdfViewerParams(
              minScale: 0.0001,
              onViewerReady: (document, controller) async {
                final random = Random();
                while (true) {
                  if (!controller.isReady) return;
                  final count = controller.pageCount;
                  await Future.delayed(const Duration(milliseconds: 300));
                  if (!controller.isReady) return;
                  final pageNumber = random.nextInt(count) + 1;
                  await controller.goToPage(pageNumber: pageNumber);
                }
              },
            ),
          ),
        ),
      ),
    );
  }
}

[jezell]

I'd guess this should be sufficient for getting it to leak every once and a while. The more viewers you have on the screen, the easier it is to reproduce leaks since it primarily happens when widget is removed from the tree during a render operation. It can be hard to see that it is leaking, but I put together a widget that allows you to track the usage of the canvaskit heap on web a while back:

https://github.com/jezell/mem_test/tree/main/lib

It can be hard to track whether things are leaking without a counter like this, since there isn't currently browser tool or API call in flutter that will show you when it is leaking. Web will start out using 128 MB of memory in the CanvasKit WASM module. The memory will grow if you start using more than that. The MemoryMonitor widget will print out the current size of the CanvasKit heap, so you see how it grows over time.

The sample there also shows how (on web) to completely avoid canvaskit heap usage by using a new API that I added to Flutter, createImageFromTextureSource. In the next release, I believe that we'll switch decodeImageFromPixels to use this API by default, but nothing prevents individual libraries from using it now to be more safe and reduce memory problems on web. That will make leaks less prone to crashing flutter web apps since it doesn't use any of the canvaskit heap for the image data.

[espresso3389]

@jezell You told me that "if you scroll around quickly in the ListView, sometimes it only takes 30 seconds to generate 2 GB worth of cached PDF images with pdfrx viewers and run the browser out of memory and crash flutter due to these bugs and leaks." but I didn't see any such large leaks and could not see your point.

Could you give me some solid example code that causes such memory leaks with some sample PDF file?

[espresso3389]

OK, after running a modified version of app several minutes, I finally reproduce the memory leak issue.

Now, I'm investigating the way to fix it anyway.

[espresso3389]

@jezell By the way, the value of _canvasKitMemory does not seem to change runtime. Is it the pre-allocated memory size or such?

[jezell]

CanvasKit WASM memory pool starts at 128 MB, SkWASM rendererer starts lower at something like 32 MB. It will grow as needed if it runs out of space. The easiest way for that to happen is if large images are allocated with decodeImageFromPixels before the old ones being freed. The WASM module has it's own heap and can only grow but never shrink. Unfortunately, the call exposed by default only shows the size of the heap, but not the free space in the heap. I have experimented with local builds of canvaskit that expose more detailed information about the free and used space via mallinfo call rather than just the total heap space, but it requires building the canvaskit WASM module from scratch and exporting mallinfo.