Severe Memory Leak and OOM Crash with Multi-Threading on Nim 2.2.10

[null-flame]

Hello. I have detected a severe memory leak in Prologue when handling high-concurrency traffic under load testing using --threads:on with Nim 2.2.10. The memory accumulates rapidly until it completely fills the RAM and SWAP, freezing the desktop environment, and forcing the Linux kernel to trigger the OOM Killer.

:

Nim Version: 2.2.10

Prologue Version: 0.6.8 (Latest)

OS: Linux fedora

Compiler Flags used: nim c -d:release --mm:orc --opt:speed main.nim (Also tested with -d:danger and --panics:on, with the same leaking result).

Minimal Code Used:

import prologue

proc hello(ctx: Context) {.async.} =
  resp "a"

let app = newApp()
app.get("/", hello)
app.run()

Step-by-Step Chronological Observations (Based on attached screenshots):

Before Test (Idle): The server starts cleanly, spawning 4 threads, consuming a negligible amount of memory.

First Test: I ran bombardier -c 700 -d 20s http://127.0.0.1:8080/. The server handles ~85k RPS beautifully, but memory (RES) suddenly spikes to 4647M (~4.6 GB) per process and never drops back down after the test finishes.

Second Test (Consecutive): Running the exact same bombardier command a second time immediately forces the memory to shoot up to 5440M, and then rapidly climbs to 5523M (~5.5 GB).

The Crash: At this point, the physical RAM (7.30 GB / 7.68 GB) and SWAP (7.68 GB / 7.68 GB) are completely maxed out. The system completely freezes (Gnome-shell starts panicking with "Application Stopped - Device memory is nearly full").

The OOM Kill: Finally, the process is forcefully killed by the OS: [1]  19178 killed  ./main.

It seems like the HTTP Context or connection/response buffers are not being garbage collected or deallocated by the ORC memory management when crossed over thread boundaries. Could you please look into how thread-local memory or async buffers are handled during high-concurrency connection closures? Thank you!

[null-flame]

Update: I just tested the exact same scenario with --threads:off. The heavy memory growth still persists, initially peaking at around 45% of total RAM. It drops at an extremely slow rate (for instance, sitting at around 41.8% after a while). Due to this high memory pressure, the OS was forced to swap out about 2.43 GB into SWAP.

While I can't be 100% certain without deeper profiling tools, this new data suggests that the issue might not be a multi-threading synchronization flaw. Instead, it seems highly likely that async connections or the underlying I/O buffers (perhaps within the core framework or httpbeast) are being retained and not fully deallocated after high-concurrency traffic drops.

[RokkuCode]

not a solution but you could give prologue with kairos backend a shot: https://github.com/jmgomez/prologue-kairos-example