Fix memory leak when viewing many files#243
Open
AlexB7 wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix for a memory leak when viewing many files in a folder. Eventually all RAM will be used resulting in swapping or a freeze. Fixes issues #234, #48 and #36.
Claude Code was used to find and fix this bug. Claude output:
The bug (present since the 2016 eog→xviewer fork, matching issue #36 from 2017 and upstream eog bug #674284 from 2012):
In src/xviewer-jobs.c, xviewer_job_load_run(), xviewer_job_save_run(), and xviewer_job_cancel() each take an extra g_object_ref(job) that's meant to be released either by an early-return path or by the g_idle_add_full(..., g_object_unref) completion callback. The early-return paths (triggered when a job gets cancelled) were missing the matching g_object_unref — unlike the sibling xviewer_job_copy_run/xviewer_job_transform_run, which handle this correctly. Since navigating to a new image cancels any still-in-flight load job for the previous one, this leaks the XviewerJobLoad object — and therefore the XviewerImage and its decoded GdkPixbuf pixel buffer — every time a load is interrupted by browsing forward, which is exactly what happens during normal/fast browsing or slideshow mode. This is almost certainly the actual long-standing leak.
A second, unrelated, newer bug in src/xviewer-image.c (introduced by commit c43d002, Nov 2025) that leaked the GdkPixbufAnimation on every static-image load was also fixed. That one was real but wasn't the historical leak — it only exists in builds after that commit.