Server segfaults under concurrent local-embedding load

[koladefaj]

Severity: high (takes down the whole memory server; data survives on disk)

Environment

Supermemory Server	0.0.5 (self-hosted, official installer)
Runtime	Bun v1.3.4 (5eb2145b), Linux x64
Deployment	Docker (debian:bookworm-slim), single container, docker compose
Host	Windows 11 + Docker Desktop, 8 GB RAM available to the engine
Embeddings	local, Xenova/bge-base-en-v1.5, 768d, native backend
Endpoints used	/v3/documents, /v4/memories, /v4/memories/list, /v4/search

Summary

The server process crashes with a native segmentation fault (a Bun panic) when
several embedding operations run concurrently against the local embedding engine
— e.g. ingesting multiple documents while also issuing search queries. The crash
is in native code, not recoverable in-process, and restart: unless-stopped
does not revive it because the panicked process does not exit cleanly.

Local embeddings via Xenova/bge-base-en-v1.5. The server logs its own
ingest limit as "2 concurrent"; the crash occurs when that is exceeded.

Steps to reproduce

1. Self-host Supermemory 0.0.5 with local embeddings (no cloud embedding key).
2. In a short window, drive concurrent embedding work against one container:
   • POST /v3/documents for several documents at once (each triggers ingest +
     embedding), and
   • a burst of POST /v4/search (searchMode: "memories") queries.
     In our case: syncing 4 chapter documents in parallel, immediately followed by
     ~8 paragraph checks each issuing 1–2 similarity searches.
3. Observe the server process panic and stop responding (connection refused on
   :6767).

Expected

The engine bounds or queues embedding work to its stated concurrency limit and
stays up; excess load waits rather than crashing the process.

Actual

Native segfault on the main thread; server dies.

Full crash block from the server log:

  + local embeddings  1 worker ready · native backend · 59s
[ingest] memory limit 1.0 GB above baseline (1.8 GB) · 2 concurrent — set SUPERMEMORY_EMBEDDING_RAM_LIMIT=ngb to change
  * embeddings
  + embeddings  local · Xenova/bge-base-en-v1.5 · 768d · 86ms
[ingest] memory limit 1.0 GB above baseline (1.8 GB) · 2 concurrent

CPU: sse42 popcnt avx avx2
Args: "/root/.supermemory/bin/supermemory-server"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) abort_signal(79) fetch(38) http_server jsc standalone_executable workers_spawned napi_module_register process_dlopen(2)
Elapsed: 2775829ms | User: 239971ms | Sys: 98682ms
RSS: 0.02ZB | Peak: 1.89GB | Commit: 0.02ZB | Faults: 1 | Machine: 8.13GB

panic(main thread): Segmentation fault at address 0x755A46505845
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:

 https://bun.report/1.3.4/l_15eb2145kwGuhooCkyo8vE+kgP__________________A2016BqkshqmC

Notes on the crash block:

• napi_module_register + process_dlopen + workers_spawned in Features
  confirm the embedding engine is a native (NAPI/dlopen) module — the segfault
  is in native code, not managed JS (a JS bug would throw, not panic).
• Peak: 1.89GB of Machine: 8.13GB → not an OOM; it's a memory-safety fault
  under concurrency. (RSS/Commit reading 0.02ZB are garbage values printed
  by the crashed accounting, themselves a symptom of the corruption.)
• The bun.report URL is the runtime's own crash-reporter link, further
  indicating the fault is in the Bun runtime the server is built on.

Impact

Any client that parallelises ingestion + search (a reasonable pattern) can crash
the server. For us it interrupted work twice, including near a demo recording.

Workaround

Client-side, cap concurrent embedding-touching requests at the engine's limit
(2). We added semaphores around both document sync and search-heavy work. This
stops provoking the bug but does not fix it. docker compose restart supermemory recovers in ~5s with data intact (the on-disk volume is not
corrupted by the crash).

Suggested fix

Bound/queue embedding jobs to the configured concurrency inside the engine so
overload backpressures instead of segfaulting; surface a Bun crash report to the
Bun team via the emitted bun.report URL if the fault is in the runtime itself.

[linear-code]

ENG-1096