Reporting bugsalpha

What to include in a moxzi bug report so it can be reproduced.

Email bug reports to austin at rivvir.com. The issue tracker isn't public during the alpha.

What to include#

Item	How to get it
Which tool	`moxzi`, `moxzid`, `moxzi-web`, an actor platform, or the on-chain builder
Version	`moxzi --version`, `moxzid --version`, or `GET /version`
The compiler you used	`moxzi info` prints the compiler's and linker's hashes
A small program that shows the bug	One `.mo` file if possible, plus `mops.toml` if it needs packages
The command and its complete output	Copy it; don't paraphrase
What you expected, and why	`moc`'s output, the IC's behaviour, or the documentation

Compiler bugs#

If moxzi rejects a program that moc accepts, or the reverse, include moc's output for the same file:

moxzi build bug.mo
moc --check bug.mo

If the compiled program misbehaves, build it unlinked too, which helps tell a compiler problem from a linker problem:

moxzi build bug.mo -o bug.wasm
moxzi build bug.mo --no-link -o bug-unlinked.wasm
shasum -a 256 bug.wasm bug-unlinked.wasm

M9000 unimplemented and Error: canister trapped with no file location are always compiler bugs.

Runtime bugs#

For a problem in moxzid, include the server's log with --log-json, the actor's /history/ACTOR output, and the requests you sent. Say whether the same actor behaves differently on the IC or under dfx.

Before you report#

Check	Why
Run `which moxzi` and `moxzi --version`	An older binary earlier on your `PATH` is a common cause
Check that no old `moxzid` is still running (`lsof -i :7000`)	It would answer instead of the one you started
Run `moxzi cache clear`	Rules out a stale cached compiler