Long-term RSS growth in Scrypted plugins is glibc malloc retention, not actual memory leak

[Ruuuuu-Bu]

Long-term RSS growth in Scrypted plugins is glibc malloc retention, not actual memory leak

TL;DR

After investigating apparent memory leaks in three Scrypted plugins (homekit, prebuffer-mixin, snapshot), I found the root cause is glibc malloc retention, not native memory leaks. A single malloc_trim(0) call via gdb reclaimed 596 MB across the three plugins (homekit alone freed 350 MB). V8 heap was constant throughout. The "leak" disappears completely after trim.

This affects anyone running Scrypted on resource-constrained hosts (e.g., 2 GB LXC, small VMs). On hosts with 8+ GB RAM the symptom takes longer to surface but still accumulates.

Setup

• Scrypted v0.135.x, homekit plugin v1.2.65, hap-nodejs v1.1.x (the .local fork bundled by Scrypted)
• Debian 12 LXC, 2 GB / 2 cores, kernel 6.x
• Node.js v22.22.2 (NodeSource)
• 16 cameras (UniFi Protect → HomeKit, all standalone mode), 4 with prebuffer enabled
• HKSV recording disabled on all cameras (mode = "Stream", not "Stream and Allow Recording")
• glibc 2.36 (default malloc, no MALLOC_ARENA_MAX tuning)

Symptom

After every systemctl restart scrypted, LXC used memory starts at ~580 MB and grows linearly:

hour  0 (warmup): 580 MB used
hour 12          : 695 MB
hour 24          : 770 MB  → projected OOM at ~30 days

Per-plugin RSS at hour 22 (post-restart):

• homekit: 130 → 515 MB (+385 MB)
• prebuffer-mixin: 199 → 333 MB (+134 MB)
• snapshot: 74 → 218 MB (+144 MB)

V8 heap (process.memoryUsage().heapUsed) was stable at 80 MB / 14 MB / 14 MB respectively across the same period — the growth is entirely outside the JS heap.

Investigation steps

1. Heap snapshots (v8.writeHeapSnapshot() via Scrypted plugin REPL TCP socket): essentially flat. homekit went from 49.3 MB → 49.8 MB in 10 hours. Confirmed leak is not in JS objects.

2. /proc/PID/smaps analysis: for homekit, 354 MB of the 512 MB RSS sat in the single [heap] mapping. The remaining 105 MB was distributed across ~350 small [anon] mappings (256 KB each — the standard glibc mmap chunk size for >128 KB allocations).

3. smaps diff over 46 minutes (during low-activity period): [heap] grew 0 KB, [anon] cycled with high churn but net +0.6 MB. Growth is bursty, correlated with HAP activity (motion events from UniFi Protect, HomeKit hub polling).

4. malloc_trim(0) via gdb:

   gdb -batch -ex "attach $PID" -ex "call (int)malloc_trim(0)" -ex "detach" -ex "quit"
   

   Result:

   homekit:         515 MB → 165 MB  (-350 MB)
   prebuffer-mixin: 333 MB → 211 MB  (-123 MB)
   snapshot:        218 MB →  94 MB  (-123 MB)
   ─────────────────────────────────
   LXC used:        917 MB → 700 MB  (-217 MB physical, the rest was shared pages)
   

   The fact that malloc_trim(0) reclaimed this much memory proves the native code is calling free() correctly — glibc is just holding the freed memory in its arena free lists for reuse instead of returning it via madvise(MADV_DONTNEED) or munmap().

Why this happens

This is documented glibc behavior. ptmalloc2 (glibc's allocator) creates per-thread arenas (default cap: 8 × num_cores, so 16 on a 2-core box). Each arena keeps freed chunks in size-class bins. Memory is only returned to the OS when:

• the arena's "top chunk" is at the end of the heap and exceeds M_TRIM_THRESHOLD (default 128 KB), OR
• malloc_trim() is explicitly called

For a Node.js process under high allocation churn (every HAP event, every motion notification, every HKSV frame, every TLS handshake → many small mallocs and frees), fragmentation and bin retention prevent the natural top-chunk trim from triggering. The arena keeps freed memory indefinitely.

References:

• Algolia, "When allocators are hoarding your precious memory" (this matches our pattern exactly)
• Heroku Dev Center, "Tuning glibc Memory Behavior"
• Node.js help Unraid Docker + Nvidia #1518 "Node.js process rss keeps rising when heapUsed/heapTotal does not"

Why it's particularly visible in Scrypted

1. Long-running daemon (designed to run 24/7).
2. High allocation churn in HAP path: ChaCha20-Poly1305 session state, mDNS query/response buffers, HAP characteristic update notifications, prebuffer ring buffers.
3. Multi-camera HomeKit standalone mode multiplies the workload — each camera has its own HAP server with its own TLS sessions.
4. Resource-constrained deploys (2-4 GB LXC/Pi setups) hit the ceiling fast.

On a 16 GB host it would still leak; users just don't notice until much later.

Existing related issues that I believe trace back to this

• Memory leak - linear memory consumption #729 "Memory leak - linear memory consumption"
• Memory usage climbing linearly, then resetting, after reset NVR events have disappeared #810 "Memory usage climbing linearly..."
• Very High Memory Usage #613 "Very High Memory Usage"
• Discussion High memory usage, what’s wrong? #1219 / Issue High memory usage, what’s wrong? #1218 "High memory usage"

None of these mention glibc retention or malloc_trim. They were closed without root cause.

Suggested fixes

In order of how invasive they are:

1. Periodic malloc_trim(0) via cron (workaround, no code change)

Daily cron, 1 second per process:

for pid in $(pgrep -f 'child @scrypted/'); do
    gdb -batch -ex "attach $pid" -ex "call (int)malloc_trim(0)" -ex "detach" -ex "quit"
done

Pros: trivial to deploy, no Scrypted change.
Cons: external scheduling, gdb dependency.

2. MALLOC_ARENA_MAX=2 env var (built-in glibc tuning)

In the systemd unit:

Environment=MALLOC_ARENA_MAX=2

Reduces per-thread arena count, concentrates allocations, glibc has a better chance of returning whole arenas. Requires Scrypted restart. No documented downside for this workload.

3. Switch to jemalloc via LD_PRELOAD (more invasive)

Environment=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2

jemalloc's default dirty_decay_ms/muzzy_decay_ms actively returns freed memory to the OS. Many large projects (Redis, MariaDB, Firefox) ship jemalloc for exactly this reason.

4. In-process periodic malloc_trim (cleanest)

Add a Scrypted-side periodic call:

import { dlopen, dlsym } from 'node:ffi-napi'; // or via a small C++ addon
setInterval(() => {
    if (process.platform === 'linux') {
        // call libc malloc_trim(0)
    }
}, 30 * 60 * 1000); // every 30 min

This makes the fix portable across deploy methods.

Reproduction (minimal)

1. Fresh Scrypted install on a Linux host with default glibc.
2. Add 4+ cameras with at least 1 in HomeKit standalone mode.
3. Let it run for 12+ hours.
4. Compare process.memoryUsage().rss vs heapUsed and the size of [heap] in /proc/<plugin-pid>/smaps.
5. Run the gdb malloc_trim(0) call — observe RSS drop while plugins continue functioning normally.

Closing thought

Posting this not as a bug report — glibc retention isn't a Scrypted bug — but to give other users a name for what they're seeing, and to invite a discussion about whether Scrypted should ship with one of the fixes above by default. Happy to provide more data or run targeted experiments.