OOM kill on persepolisdm (anon-rss ~4.5GB) when downloading a single large file (8.40GB) via Firefox add-on — memory leak in built-in downloader, not aria2

Title: OOM kill on persepolisdm (anon-rss ~4.5GB) when downloading a single large file (8.40GB) via Firefox add-on — memory leak in built-in downloader, not aria2

Environment

• Persepolis version: 5.1.1 (package: persepolis-5.1.1-7.fc44.noarch)
• Distro: Fedora 44
• Install method: distro repository (dnf/rpm)
• Total system RAM: 4 GB
• Free disk space at destination: 222 GB (not a disk-space issue)
• Max download speed: ~1.5 MB/s (a slow connection, ruling out high-throughput I/O pressure)
• Download initiated via: Persepolis's official Firefox browser extension (not the standalone persepolis GUI or manual aria2c usage)
• No standalone aria2c process was found running during the download (ps aux | grep aria2c returned nothing) — consistent with 5.x having removed the external aria2 dependency in favor of an internal Python downloader.

Summary

Downloading a single large file (8.40 GB) through Persepolis (triggered from the Firefox add-on) reliably crashes the persepolisdm process itself via the Linux OOM killer. This happened 3 separate times across different sessions/service instances, always with persepolisdm's anonymous RSS memory (private heap, not file-backed page cache) climbing to roughly 4.3–4.7 GB before being killed — i.e. consuming essentially all available RAM on a 4GB machine.

Key point: the process killed is persepolisdm (the app's own Python/PyQt process), not aria2c. file-rss in every kill event is negligible (1–56 MB), which rules out disk-write/page-cache buildup as the cause. This strongly points to a memory leak inside Persepolis's own code (likely in progress-tracking/segment-tracking data structures for large files), not in disk I/O or connection handling.

Steps to reproduce

1. Install Persepolis 5.1.1 on a system with ~4GB RAM.
2. Install/use the official Persepolis Firefox add-on.
3. Start a download of a single large file (~8.4 GB in my case) via the add-on.
4. Let the download run; persepolisdm's memory usage grows steadily until it is killed by the kernel OOM killer before the download completes.

Expected behavior

Memory usage should stay roughly constant (a few hundred MB at most) regardless of the size of the file being downloaded, since data should be streamed to disk rather than accumulated in memory.

Actual behavior — dmesg / OOM killer log

[Sat Aug 29 15:28:18 2026] DownloadLink invoked oom-killer: gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO|__GFP_COMP), order=0, oom_score_adj=200
[Sat Aug 29 15:28:18 2026] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/[email protected]/app.slice/app-com.github.persepolisdm.persepolis@129349f8759944c08c7a81391695c49b.service,task=persepolisdm,pid=389176,uid=1000
[Sat Aug 29 15:28:18 2026] Out of memory: Killed process 389176 (persepolisdm) total-vm:11707368kB, anon-rss:4311552kB, file-rss:56656kB, shmem-rss:2980kB, UID:1000 pgtables:15604kB oom_score_adj:200

[Sat Aug 29 15:39:08 2026] gmain invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
[Sat Aug 29 15:39:08 2026] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/[email protected]/app.slice/app-com.github.persepolisdm.persepolis@51b56b5df92e41d6a95970d0bc0a309d.service,task=persepolisdm,pid=392323,uid=1000
[Sat Aug 29 15:39:08 2026] Out of memory: Killed process 392323 (persepolisdm) total-vm:10629216kB, anon-rss:4709724kB, file-rss:4668kB, shmem-rss:2944kB, UID:1000 pgtables:16020kB oom_score_adj:200

[Sat Aug 29 15:39:41 2026] kworker/u33:1 invoked oom-killer: gfp_mask=0x2cc0(GFP_KERNEL|__GFP_NOWARN), order=0, oom_score_adj=0
[Sat Aug 29 15:39:41 2026] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/[email protected]/app.slice/app-com.github.persepolisdm.persepolis@599b5692b61d409380c3b902df91c401.service,task=persepolisdm,pid=392917,uid=1000
[Sat Aug 29 15:39:41 2026] Out of memory: Killed process 392917 (persepolisdm) total-vm:10304644kB, anon-rss:4586744kB, file-rss:1188kB, shmem-rss:12008kB, UID:1000 pgtables:16548kB oom_score_adj:200

Note the consistent pattern across all three independent crashes: anon-rss in the 4.3–4.7 GB range, file-rss negligible.

What I already tried

• Lowering "Number of connections" (down to 4–8) and increasing "Chunk size (KiB)" to the maximum available in the UI (1024 KiB) — reduced severity somewhat but did not fix the underlying leak, since the crashing process is the app itself and not an external aria2 process.
• Confirmed no standalone aria2c process exists during the download — the built-in Python downloader introduced in 5.0 appears to be handling everything in-process.

Notes

• I'm sharing this mainly for diagnostic value in case it helps identify the leak — I likely won't be able to actively follow up on this issue with further back-and-forth, but I'm happy to have posted the raw log data as-is. If a maintainer needs anything else from me, I'll do my best to respond, but please don't expect fast turnaround.