Fix memory leak when viewing many files

[AlexB7]

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.

---

Additional findings:

Root cause: xviewer_window_reload_image() (src/xviewer-window.c:6587) nulls out window->priv->image before the reload's background job finishes. When the job completes, xviewer_job_load_cb() (line 1360) only disconnects the previous "thumbnail_changed"/"file-changed" signal handlers if priv->image != NULL (line 1378) — but since reload_image() already nulled it, that guard is skipped. xviewer_window_display_image() is then called and unconditionally adds another pair of signal connections (lines 934–940) onto the same XviewerImage object (the list store reuses the same object when the file-monitor sees the same path change, rather than creating a new one). So every time the watched file changes on disk (exactly what your test does by overwriting /tmp/leaktest.png in place), one more redundant handler pair accumulates permanently on that image object — they're never cleaned up. Each additional handler is small, but they never get removed and each one re-fires (and does its own work, e.g. thumbnail regeneration) on every subsequent change, which matches a slow, continuing — but not exploding — growth in RSS.

While auditing this path I also noticed a smaller, unrelated genuine bug in src/xviewer-list-store.c's file_monitor_changed_cb: in the G_FILE_MONITOR_EVENT_DELETED case it fetches image via gtk_tree_model_get (transfer-full) but never g_object_unrefs it, unlike the CHANGES_DONE_HINT case just above. It wouldn't fire in your test (no delete event, just in-place overwrite), but it's worth fixing too.

Summary:

Why VmRSS grew from 104060 kB → 126272 kB across the extra 270 cycles: there's a third, separate leak — this one specific to your test's pattern of repeatedly overwriting the same open file (rather than navigating between files), which is exactly the scenario in the original 2012 upstream bug report (a motion-style webcam tool rewriting one file in place).

Root cause: xviewer_window_reload_image() (xviewer-window.c:6587, triggered by the GFileMonitor "file changed" → auto-reload path) sets priv->image = NULL before the reload's background job finishes. The job-completion callback xviewer_job_load_cb() only disconnects the old "thumbnail_changed"/"file-changed" signal handlers when priv->image != NULL — but it's already NULL by then, so that cleanup is skipped. xviewer_window_display_image() then unconditionally adds another pair of signal handlers onto the same XviewerImage object (the list store reuses one object per path rather than creating a new one on a plain modify). So every overwrite of your watched file leaks one more permanent signal-handler pair, and each surviving stale handler keeps re-firing (redoing its own work) on every subsequent change — a slow, genuinely-still-growing leak rather than a one-time cost, matching your 300-cycle data.

Fixed by making the signal connection idempotent (disconnect-then-connect, mirroring the pattern already used correctly elsewhere in the same file). I also fixed a smaller, unrelated ref leak I spotted in the same code path (xviewer-list-store.c, G_FILE_MONITOR_EVENT_DELETED case never unreffed the fetched image — doesn't fire for in-place overwrites, so not your test's cause, but a real bug).

---

Found and fixed two more real leaks, and rigorously bisected a much smaller residual one. Summary:

Two more genuine bugs fixed (same pattern as before — a missing g_object_unref on an early-return path):

• xviewer_job_thumbnail_run (xviewer-jobs.c) leaked its job ref whenever thumbnail loading failed.
• xviewer_thumbnail_load (xviewer-thumbnail.c) leaked a small XviewerThumbData struct on its "already known to fail" early return.

Where the ~85 KB/cycle residual leak stands: I built the project directly from source, ran the repro under Valgrind and then with direct in-process mallinfo2() checkpoints (immune to allocator-fragmentation noise, unlike RSS) at ~10 points through the reload pipeline. That bisection:

• Confirmed most of your originally-observed growth (e.g. 86MB→457MB) was the big bugs, now fixed — a clean 600-cycle run after the first 2 fixes plateaus/grows only slowly.
• Proved a smaller, rock-steady ~85 KB leaks every single cycle, even with all 6 fixes applied.
• Ruled out thumbnail generation entirely (leak persists identically with it disabled), and ruled out xviewer_image_real_load, xviewer_window_reload_image, and xviewer_job_load_cb each individually — all clean.
• Narrowed it to the chain handle_image_selection_changed_cb → new job creation → xviewer_job_scheduler_add_job → background thread start, but couldn't pin an exact line — none of the individual allocations there (job object, 2 signal closures, a status string) obviously total 85 KB.

This residual leak only shows up in the narrow "same file repeatedly overwritten in place while open" scenario (your test's exact pattern, and the original 2012 webcam-monitoring bug report) — it's ~100-200x smaller per event than what's already fixed, which covered ordinary image navigation/browsing.