unsafe precondition(s) violated: ptr::write requires that the pointer argument is aligned and non-null

[Kalan]

First report on this - happy to make an MRE if that helps. It may not even be a bug, but I don't know that yet.

Situation:

1. I'm adding threading support to a library compiled to WASM for use in the browser. The app uses serde-yaml. The app has worked quite well for some time, and this issue appeared when adding the required build flags from the docs:

[unstable]
build-std = ['std', 'panic_abort']

[build]
target = "wasm32-unknown-unknown"
rustflags = '-Ctarget-feature=+atomics,+bulk-memory'

My first thought is that this panic might be "expected" and otherwise caught somewhere in the stack above with unwind and that's broken with the use of abort, but I'm not seeing a panic recovery here or in serde-yaml. Maybe I'm just missing it.

2. Build succeeds, but the binary panics and emits the following error at runtime:

lib_bg.wasm:0x14dab71 Uncaught (in promise) RuntimeError: unreachable
    at std::sys::wasm::common::abort_internal::hb32c013b124a63c5
    at std::panicking::rust_panic_with_hook::h8d83516cdb4f9a91
    at std::panicking::begin_panic_handler::{{closure}}::hf16a9ba57012eb4
    at std::sys_common::backtrace::__rust_end_short_backtrace::h16a9293adcf4d4fb
    at rust_begin_unwind
    at core::panicking::panic_nounwind_fmt::ha0e10cdd15fcadb1
    at core::panicking::panic_nounwind::h277c78959cb6049e
    at core::ptr::write::hcbc9dd9a199faf58
    at unsafe_libyaml::scanner::yaml_parser_fetch_stream_start::hecc19e1d6f4b1357
    at unsafe_libyaml::scanner::yaml_parser_fetch_next_token::h5f7a3b945d3253ad

So, it appears to be in here. If this is expected or intractable, I can always migrate the app off of YAML serialization, but it'd be nice to keep it in there if I can.

Versions:

➜  cargo tree -i unsafe-libyaml
unsafe-libyaml v0.2.9
└── serde_yaml v0.9.25
      ...

Thanks!

[David Tolnay]

Thanks for the report! This is definitely a serious bug in this crate.

I found one bug that I think would cause this crash when running on a 32-bit architecture such as wasm. I tried reproducing the crash using MIRIFLAGS='-Zmiri-disable-isolation' cargo miri test --target i686-unknown-linux-gnu which also should be 32-bit. I didn't manage to observe a crash this way, but I think that is a coincidence of miri's allocator working differently than wasm's.

#24 has the fix and is published in unsafe-libyaml 0.2.10. Could you try this in your use case and let me know whether it's fixed?

[Kalan]

Worked like a charm, thank you for the quick fix!