Memory leak when reloading a document over and over

[Holbormon]

Describe the bug
I believe the autoreload-on-change feature combined with the rendered page caching mechanism causes a memory leak over long work sessions.

To Reproduce
Open a presentation in pympress, work on it by periodically editing and reloading for a few hours, realise you have no ram left, close pympress, ram is restored.

Expected behavior
The rendering cache should probably be flushed whenever the document is reloaded, or maybe, every few (possibly configurable) reloads ?

Additional context
I've been running the default config (cache set to 200 pages) but I have 32GB of ram, so it seems out of place for a work session of a few hours to consume everything.

Environment (please complete the following information):

• OS: btw I use arch Linux 6.17.5-arch1-1
• Python version: 3.13.7
• Pympress version: 1.8.6
• Installation method: AUR python-pympress

Thanks for your work, this lightweight and powerful piece of software really fills a very crucial niche in the ecosystem of Linux PDF readers !

[Cimbali]

pympress clears the rendering cache on every document load, and manually invokes garbage collection too. I have to see what slips between the cracks.

[Holbormon]

Not sure if it helps, but here is an excerpt of ps -fu while pympress is running, with a rough breakdown of RAM usage:

PID    %CPU %MEM    VSZ   RSS      STAT START   TIME COMMAND
271905 35.3 32.4 21976352 10558432 Sl+  17:28   4:53 /usr/bin/python /usr/bin/pympress some-file.pdf
271920  0.0  0.0   3004  1912      S+   17:28   0:00  \_ bwrap --unshare-all --die-with-parent --chdir / --ro-bind /usr /usr --dev /dev --ro-bind-try /etc/ld.so.cache /etc/ld.so.cache --ro-bind-try /nix/store /nix/store --tmpfs /tmp-home --tmpfs /tmp-run --clearenv --setenv HOME /tmp-home --setenv XDG_RUNTIME_DIR /tmp-run --setenv XDG_RUNTIME_DIR /run/user/1000 --symlink /usr/lib /lib --symlink /usr/lib /lib64 --seccomp 24 /usr/lib/glycin-loaders/2+/glycin-image-rs --dbus-fd 23
271921  0.0  0.0   3004  1256      S+   17:28   0:00      \_ bwrap --unshare-all --die-with-parent --chdir / --ro-bind /usr /usr --dev /dev --ro-bind-try /etc/ld.so.cache /etc/ld.so.cache --ro-bind-try /nix/store /nix/store --tmpfs /tmp-home --tmpfs /tmp-run --clearenv --setenv HOME /tmp-home --setenv XDG_RUNTIME_DIR /tmp-run --setenv XDG_RUNTIME_DIR /run/user/1000 --symlink /usr/lib /lib --symlink /usr/lib /lib64 --seccomp 24 /usr/lib/glycin-loaders/2+/glycin-image-rs --dbus-fd 23
271922  5.3  4.9 6285712 1618728   Sl+  17:28   0:44          \_ /usr/lib/glycin-loaders/2+/glycin-image-rs --dbus-fd 23

Which seems to rule out a leak in child processes, as it's really the parent process which consumes 10+ GB ram after barely half an hour of work.

[Cimbali]

So I’ve been watching for a bit, reloading and cycling through all pages of a reasonably large document on a loop (67 pages, reload loop took roughly a minute). Memory usage is stable at 1.9%

Every 2.0s: ps -o pid,stat,pmem,start,comm 266531                                              08:24:49
    PID STAT %MEM  STARTED COMMAND
 266531 Rl    1.9 07:48:25 pympress

On the other hand, I don’t think there should be subprocesses at all and I don’t know what glycin is. (And bwrap is some sandboxing tool??) Seems to be what Gtk uses to load images now from a quick read.

Could I get:

• The output of head -n2 ~/.cache/pympress.log (of a clean log file if possible)
• The pdf file you’re using, or a smaller version that reproduces the issue? You can send this to me privately if you prefer.

[Holbormon]

I have managed to narrow down the problem to the following MRE, based on .gif animations specifically:

\documentclass{beamer}

\usepackage{multimedia}

\newcommand{\gif}[4]{\movie[autostart,loop,width=#1,height=#2]{\includegraphics[width=#1,height=#2]{#4}}{#3}}

\begin{document}

    \begin{frame}

        \gif{6cm}{4cm}{nyancat.gif}{nyancat.png}

    \end{frame}

\end{document}

which when repeatedly compiled with pdflatex causes pympress to leak. Here are the files involved:

nyancat.gif
nyancat.png

And here is pympress.log:

INFO:pympress.app:Pympress: 1.8.6 ; Python: 3.13.7 ; OS: Linux 6.17.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 02 Nov 2025 17:27:22 +0000 ; Gtk 3.24.51 ; GLib 2.86.1 ; Poppler 25.10.0 cairo ; Cairo 1.18.4 , pycairo 1.28.0
INFO:pympress.extras:Media support: GdkPixbuf gif player, GStreamer 1.26.7, VLC disabled

[Cimbali]

Ah fantastic, that narrows it down! Thanks a million.

[Cimbali]

Check 922b699 which reduces the leakage by a lot, but not entirely it seems. Also I need to test it on other media backends before merging it.

[Holbormon]

Thanks for the tentative mitigation !

If it's worth anything, I have managed to reproduce the leak without any reload involved: I have a presentation including a .gif file which is about 3 mins long (111MiB), and compiles into a ~9MiB PDF, which when opened by pympress causes an out of memory in under a minute. I am still using the \gif command posted earlier.

EDIT: Maybe it's worth noting that the same command used with the original (half the size) .mp4 from which my .gif was converted, does not leak.

[Cimbali]

Huh, that’s interesting. You’re positive there’s no reload? I wonder how big the gif is uncompressed. But even then we should not reach OOM, the only thing we create repeatedly are pixbufs, which are explicitly owned by the animation iterator…

The caller of this function does not own a reference to the returned pixbuf; the returned pixbuf will become invalid when the iterator advances to the next frame, which may happen anytime you call gdk_pixbuf_animation_iter_advance().

Copy the pixbuf to keep it (don’t just add a reference), as it may get recycled as you advance the iterator.

Maybe we could try caching all the frames so we never call get_pixbuf() more than once per frame.

---

The current mitigation basically kills the manual gif-frame loop that we need to do to display gifs. Until then it stayed alive forever. But we only create new loops on document loads.

[Cimbali]

Could be this tbh: https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/275

glycin bug related to this API… fix was released in Gdk 2.44.3 and requires glycin-2 ≥ 2.0.1 but somehow those aren’t in the log file versions. Can you check if you have that @Holbormon?

[Holbormon]

Could be this tbh: https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/275

glycin bug related to this API… fix was released in Gdk 2.44.3 and requires glycin-2 ≥ 2.0.1 but somehow those aren’t in the log file versions. Can you check if you have that @Holbormon?

$ pacman -Qi glycin
Name            : glycin
Version         : 2.0.7-1
Description     : Sandboxed and extendable image
                  decoding
Architecture    : x86_64
URL             : https://gnome.pages.gitlab.gnome.org/glycin/
Licenses        : MPL-2.0 OR LGPL-2.1-or-later
Groups          : None
Provides        : libglycin-2.so=0-64

[Cimbali]

I seem to have GdkPixbuf 2.44.1 and so does the archlinux repo.

[Holbormon]

I seem to have GdkPixbuf 2.44.1 and so does the archlinux repo.

Apologies, I read your previous comment too quickly and missed the GdkPixbuf part. The Arch repo has 2.44.4 and so do I:

$ pacman -Qi gdk-pixbuf2
Name            : gdk-pixbuf2
Version         : 2.44.4-1
Description     : An image loading library
Architecture    : x86_64
URL             : https://wiki.gnome.org/Projects/GdkPixbuf
Licenses        : LGPL-2.0-or-later
Groups          : None
Provides        : libgdk_pixbuf-2.0.so=0-64

Also says I've had it installed for more than a month (so, prior to opening this issue).

[Cimbali]

Yes I'm still a little wary of this glycin thing as they seem to have fixed a large number of memory leaks recently (so there could conceivably be more) and no user ran into this issue before. I need to repro in an environment that has an old gdkpixbuf or one where I rebuild a non-glycin version.