CLI leaks ~10 MB of RAM per launch: bundled libopentui.so is unpacked to a temp file and never deleted (Termux/Android)

[heavymio]

What happened

Every launch unpacks the bundled libopentui.so into a temporary file and dlopens it, but never deletes the file. One file per launch, ~10 MB each, and the name is unique per launch so nothing is ever reused.

$ ls -la /tmp/.*.so
-rw-r--r-- 1 root root 10240680 Sep 27 08:59 /tmp/.1adb7be55fff07df-00000000.so
-rw-r--r-- 1 root root 10240680 Sep 27 09:00 /tmp/.1adb7bed3b9d5ee7-00000000.so
-rw-r--r-- 1 root root 10240680 Sep 27 09:05 /tmp/.1adb7abd59df37fb-00000000.so

Details that make this easy to confirm:

• size is always exactly 10240680 bytes, and the md5 is identical across launches (f29cb944…) — the same library, over and over
• the file is a valid ELF64 AArch64 shared object with SONAME: libopentui.so
• the blob is embedded in the shipped binary: a 64-byte chunk from the middle of the extracted file is present in freebuff
• exactly one file per launch, on every exit path — --version, --help, Ctrl-C, through the npm launcher, and direct execution all leak one

It leaks regardless of how the process exits, so this is not an artefact of killing it.

On Android /tmp is a tmpfs, so this is RAM, not disk. Measured over one working session: 35 launches → 35 files → 342 MB resident. At a few dozen launches a day that is roughly 300 MB/day and ~9 GB/month that nothing ever reclaims.

I have not found a way to make Bun reuse the file. Bun does have a built-in extraction path — when a compiled binary dlopens a library imported with with { type: 'file' }, Bun unpacks it to /tmp/.bun-<hash>.so — but that one is deduplicated by name, so repeated runs reuse the same file. Stock Bun 1.2.21 and 1.4.2 both do this and do not grow. The per-launch unique name here is the CLI's own extraction, so the unlink is missing on that path.

Steps to reproduce

rm -f /tmp/.*.so
freebuff --version
ls -la /tmp/.*.so        # one 10240680-byte file
freebuff --version
ls -la /tmp/.*.so        # two

Any invocation works; --version is used here only because it exits on its own. Repeat N times and you get N files.

Safe to delete while running, which makes it easy to confirm nothing depends on the file after startup:

freebuff & sleep 8; rm -f /tmp/.*.so; sleep 5; kill -0 $! && echo "still running"

That keeps the process alive with no errors, which is what makes the fix below safe.

Workaround, if a fix is not immediately available — point TMPDIR somewhere disposable and sweep it:

mkdir -p /path/to/scratch
TMPDIR=/path/to/scratch freebuff

Where does this happen?

CLI (terminal client)

Operating system

Linux

Version

0.0.204 (linux-arm64)

Model

Pixel 8 Pro (Tensor G3), aarch64, Android 16, Termux with proot-distro 5.9.0. Also reproduces on the direct binary at ~/.config/manicode/freebuff, so it is not a launcher issue.

Logs or screenshots

$ for i in 1 2 3; do freebuff --version; done
0.0.204
0.0.204
0.0.204
$ ls /tmp/.*.so | wc -l
3
$ du -ch /tmp/.*.so | tail -1
3 total
30M     <- ~10 MB per launch

readelf -d on the extracted file:

SONAME: Library soname: [libopentui.so]
NEEDED: libm.so.6, libpthread.so.0, libc.so.6, libdl.so.2

Build path baked into the library, for reference:

/Users/runner/work/_temp/.../zig-aarch64-macos-0.15.2/lib

Suggested fix

Delete the file as soon as dlopen returns — the library is mapped into the process at that point and the file is no longer read. Verified on this machine: removing it 8s into a running session leaves the process running with no errors.

import { dlopen } from 'bun:ffi'
import { unlinkSync } from 'node:fs'

const handle = dlopen(path, { symbols })
try {
  unlinkSync(path)   // mapped already; the file is no longer needed
} catch {
  // couldn't remove it — not worth failing startup over
}

If the library is reached through Bun's own embedded-file path (/$bunfs/...), no extra temp file is needed at all — unlinking the file Bun already unpacked is the whole fix.

Unrelated to #1374, but same runtime: os.cpus()[0].model throws when /proc/stat and /proc/cpuinfo disagree, which on this machine is an upstream Bun issue — oven-sh/bun#44125

[loloshelly102-a11y]

Suggested Fix

Because dlopen maps the library into the process's memory space, the physical file on disk is no longer needed the moment it finishes loading. The report suggests adding a safe unlinkSync call immediately after the dlopen operation:

javascript

import { dlopen } from 'bun:ffi'
import { unlinkSync } from 'node:fs'

const handle = dlopen(path, { symbols })
try {
unlinkSync(path) // Mapped already; the file is no longer needed
} catch {
// Couldn't remove it — not worth failing startup over
}

Temporary Workaround
Until an official patch is released, users can bypass the RAM leak by redirecting temporary files to a safe, disposable directory that can be easily wiped later:

bash

mkdir -p /path/to/scratch
TMPDIR=/path/to/scratch freebuff

[aniruddhaadak80]

Thanks for the detailed report — the ELF/SONAME evidence and the "safe to delete while
running" check make this easy to reason about.

One correction to the hypothesis in the report, based on searching this repository:
I could not find any Freebuff code that extracts a shared library to a temp file.
The complete set of .so references in the exported tree is:

• cli/scripts/open-tui-native-bundle.ts — build time only. It maps
  platform → library name (libopentui.so / libopentui.dylib / opentui.dll)
  so it can install @opentui/core-<platform>-<arch> and hash the library into
  .freebuff-native-bundle.json. It never writes a library to a temp dir.
• cli/src/__tests__/open-tui-native-bundle.test.ts — the test writes a fake
  libopentui.so into a fixture.

There is no dlopen and no bun:ffi usage in the tree either. The one runtime
native extraction that does exist is cli/src/native/ripgrep-extraction.ts, and it
is not this: it writes to path.dirname(process.execPath) — the binary's own
directory, not os.tmpdir() — and its staging directory is removed in a finally.

That points at the runtime rather than this repo. The filename shape is the clue:
.1adb7be55fff07df-00000000.so is a module id plus a -00000000 virtual module
id, which is the pattern Bun uses when it unpacks an embedded native addon from a
standalone executable, not a name this codebase would choose. It also explains why
the report's own experiment works: a dlopened file is safe to unlink, because
the mapping is already held.

So this looks like it belongs upstream of this repository rather than in the
exported paths, and I would not want to guess at a patch for it here:

• Bun — extraction/dedup/reaping of native addons embedded by
  bun build --compile. The report already notes the deduplicated shape
  (/tmp/.bun-<hash>.so) that does not grow, so the interesting question for
  Bun is why the NAPI-addon path picks a per-launch name instead.
• @opentui/core 0.3.4 — how it loads its native module.

If that is right, a fix here is not possible without changing how the addon is
loaded, which is inside @opentui/core.

Two things that would help pin it down further, if anyone has a device handy:

1. Whether the file is still created when the CLI is run from the npm-installed
   JS wrapper rather than the compiled binary, and
2. Whether a non-OpenTUI entry point leaks the same way, which would separate
   "Bun unpacks every native addon" from "OpenTUI's load path does".

Until then the TMPDIR workaround in the report looks like the right mitigation —
worth noting that on Termux TMPDIR is RAM, so pointing it at a disposable path
(or a tmpfs that is cleared) is the only lever available without an upstream fix.

[heavymio]

Answering both questions, and I think this pins it down — to Bun, not to OpenTUI.

1. npm wrapper vs the compiled binary

No difference. Both leak exactly one file per run:

via `freebuff` (npm wrapper):  0 -> 1 -> 2
via `~/.config/manicode/freebuff` (binary): 2 -> 3 -> 4

So it is not the JS launcher.

2. A non-OpenTUI entry point leaks identically

I built a minimal reproduction with no OpenTUI in it at all — a 5 KB C shared object embedded into a bun build --compile binary and loaded through dlopen on the with { type: 'file' } path:

import p from './libprobe.so' with { type: 'file' }
import { dlopen } from 'bun:ffi'
dlopen(p, { symbols: { probe: {} } })

Same leak, same 1:1 growth, same filename shape as the CLI. So this is not OpenTUI's load path — it is Bun unpacking an embedded shared object on the dlopen path.

One correction to the hypothesis in the report, though, and to my own earlier guess: it is not a NAPI addon. The extracted blob has no NAPI symbols at all:

Type:    DYN (Shared object file)
Machine: AArch64
napi in dynamic symbols: 0
SONAME:  libopentui.so
GLOBAL exports: addToCurrentHitGridClipped, audioClearPlaybackDeviceSelection, ...

It is a plain Zig-built shared library, so this is the embedded-.so dlopen path rather than the NAPI addon path.

3. The version is the whole thing

The filename shape you decoded is Bun's — and reproducing it pinned the cause. Same app.js, same embedded .so, only the Bun version differs:

Bun	run 1	run 2	run 3	filename
1.3.14	0→1	1→2	2→3	.79fffdef…-00000000.so
1.4.2	0→1	1→1	1→1	.bun-0-6260b1cd023ea996.so

1.3.14 leaves a new file on every launch. 1.4.2 extracts once and reuses it, and the name changed to the .bun-<hash>.so shape.

This repo pins .bun-version to 1.3.14, so released builds sit on the leaking side of that change.

What that means for the fix

Probably nothing to change in this repo. It looks like a Bun bug that is already fixed upstream — bumping .bun-version to 1.4.2 should be enough, no code change. That also means the TMPDIR mitigation in the report stays the right lever for users on the current binaries, which on Termux is RAM and therefore worth taking seriously.

If it is useful I can put a minimal bun build --compile + embedded-dlopen repro in a gist so it can be filed against Bun directly, since #1443 is presumably the wrong repo for it.