A clean QEMU run ruled out the instruction mismatch

I built the QEMU test expecting it to catch an illegal instruction. It came back clean in ten seconds.

That result was more useful than another failed leaderboard submission. It told me the wheel could load and generate OK under the CPU instruction profile I was targeting. The remaining problem was somewhere else.

Test the bytes that will ship

The judge CPU exposed AVX but not AVX2 or BMI2. Sandy Bridge matches those three features, so I used QEMU user-mode emulation to run the image's userspace under that CPU model.

The job exports the container filesystem, copies in a static QEMU binary, and runs a small model-loading smoke test through it:

docker export $(docker create $IMAGE) | tar -x -C rootfs
cp /usr/bin/qemu-x86_64-static rootfs/
chroot rootfs /qemu-x86_64-static -cpu SandyBridge \
  /usr/local/bin/python3 /smoke.py

This matters because the ordinary CI environment had the instructions that were missing on the judge. A unit test around the loader could verify the guard logic, but it could not make the host CPU reject an unsupported instruction.

QEMU supplied that missing condition. It ran the same filesystem and Python stack with the Sandy Bridge CPU model instead of relying on the host's exposed feature flags.

What the test does not reproduce

This is user-mode emulation, not a copy of the judge machine. It does not recreate the judge's memory limit, timing, kernel, or full hardware. It tests whether this userspace can execute under the selected CPU model.

That narrower claim is exactly what I needed. After BMI2 was disabled, the smoke test loaded the wheel in ten seconds and generated OK. The binary no longer hit an unsupported instruction in that test.

The clean run did not mean the whole submission would work. The next judge score was still poor. That left speed or memory pressure as the most likely remaining explanation for why the larger local model produced nothing useful inside the judge's limits.

A negative result can finish a branch

Before this job, I was using leaderboard scores to guess whether the model had loaded. After it, I had a direct compatibility check for the binary.

The useful result was not a reproduced crash. It was permission to stop changing CPU flags. The wheel had passed the instruction test, so cutting the context window and output limits was a more sensible next probe than another blind rebuild.

I should have made that test earlier. Not because QEMU would reproduce the whole judge, but because it could answer one question locally and let me stop asking the leaderboard.

---

This is one thread from five days debugging a black-box hackathon judge that returned one accuracy number and no logs. The full write-up is "One number, no logs".