crafter-build -r hangs at step 101/139 (no compiler running) — wasm32-wasip1 build never completes #16

New issue

Closed

opened 2026-06-01 12:54:22 +02:00 by jorijnvdgraaf · 0 comments

jorijnvdgraaf commented

2026-06-01 12:54:22 +02:00

Owner

Summary

crafter-build --target=wasm32-wasip1 --debug-api -r deterministically hangs at step 101 of 139 while compiling the 3DForts target set. The build driver stops making progress, with no compiler subprocess running, and sits there indefinitely. Reproduced twice back-to-back in the same environment.

Repro

crafter-build --target=wasm32-wasip1 --debug-api -r

(run inside the 3DForts work tree, wasm32-wasip1 target)

Observed behaviour

The build log advances normally through Crafter.Graphics, links it, then begins the Forts3D targets and freezes:

[97/97] Compiling Crafter.Graphics-Input.cpp
[98/98] Linking Crafter.Graphics
[99/139] Compiling Forts3D-Camera.cpp
[100/139] Compiling Forts3D…        <-- frozen here, never advances

The log line for step 101 is emitted ([100/139] Compiling Forts3D…) but never completes — /tmp/build.log mtime stops updating and the build never reaches 139/139.

Process state while hung

Captured ~13 minutes into the freeze:

crafter-build (the driver) is alive but single-threaded and S (sleeping), wchan 0, ~0:22 CPU total over 13+ minutes elapsed — i.e. effectively idle.
No clang / cc1 / lld / llvm / gcc process exists anywhere in the container.
No zombie/defunct processes.
The driver's only child is the -r dev server it spawns early (serve-coi.py on :8080), which keeps serving fine.

So the driver has stopped scheduling compile jobs entirely — it isn't waiting on a compiler that's still working; there is no compiler at all. It looks like the driver is blocked/deadlocked after dispatching (or after the COI server is up) rather than crashing.

Impact

The build never completes, so the served artifact is partial/stale.
Any consumer that waits for a completion marker (139/139, etc.) hangs forever — this is what stalled an automated 3DForts session twice.

Notes / leads

The -r flag starts the COI server before the build finishes (server is up at step ~100). Worth checking whether -r serve-mode interacts with the job scheduler — e.g. the build loop yields to the server and never resumes, or a pipe/handle to the spawned compiler is closed when the server starts.
The freeze point is consistent: the target immediately after Forts3D-Camera.cpp (step 101).

Environment: wasm32-wasip1, --debug-api -r, podman container (rootless), single-threaded driver.

## Summary `crafter-build --target=wasm32-wasip1 --debug-api -r` deterministically **hangs at step 101 of 139** while compiling the 3DForts target set. The build driver stops making progress, with **no compiler subprocess running**, and sits there indefinitely. Reproduced twice back-to-back in the same environment. ## Repro ``` crafter-build --target=wasm32-wasip1 --debug-api -r ``` (run inside the 3DForts work tree, wasm32-wasip1 target) ## Observed behaviour The build log advances normally through Crafter.Graphics, links it, then begins the Forts3D targets and freezes: ``` [97/97] Compiling Crafter.Graphics-Input.cpp [98/98] Linking Crafter.Graphics [99/139] Compiling Forts3D-Camera.cpp [100/139] Compiling Forts3D… <-- frozen here, never advances ``` The log line for step 101 is emitted (`[100/139] Compiling Forts3D…`) but never completes — `/tmp/build.log` mtime stops updating and the build never reaches `139/139`. ## Process state while hung Captured ~13 minutes into the freeze: - `crafter-build` (the driver) is alive but **single-threaded and `S` (sleeping)**, `wchan 0`, ~`0:22` CPU total over 13+ minutes elapsed — i.e. effectively idle. - **No `clang` / `cc1` / `lld` / `llvm` / `gcc` process exists anywhere** in the container. - **No zombie/defunct** processes. - The driver's only child is the `-r` dev server it spawns early (`serve-coi.py` on :8080), which keeps serving fine. So the driver has stopped scheduling compile jobs entirely — it isn't waiting on a compiler that's still working; there is no compiler at all. It looks like the driver is blocked/deadlocked after dispatching (or after the COI server is up) rather than crashing. ## Impact - The build never completes, so the served artifact is partial/stale. - Any consumer that waits for a completion marker (`139/139`, etc.) hangs forever — this is what stalled an automated 3DForts session twice. ## Notes / leads - The `-r` flag starts the COI server **before** the build finishes (server is up at step ~100). Worth checking whether `-r` serve-mode interacts with the job scheduler — e.g. the build loop yields to the server and never resumes, or a pipe/handle to the spawned compiler is closed when the server starts. - The freeze point is consistent: the target immediately after `Forts3D-Camera.cpp` (step 101). Environment: wasm32-wasip1, `--debug-api -r`, podman container (rootless), single-threaded driver.

jorijnvdgraaf added the

claude:ready

label

2026-06-01 13:16:18 +02:00