Rust canister backtraces

Developers
1

Is there a way to enable backtraces for panics occuring from within a Rust canister? I have a canister written in Rust that compiles just fine, but it panics somewhere within calling my dependencies, but I have almost no information on the panic: [Canister rrkah-fqaaa-aaaaa-aaaaq-cai] Panicked at 'not supported on this platform', library/std/src/sys/wasm/../unsupported/os.rs:76:5

I would love to get a detailed backtrace on that panic. Any help would be appreciated. I’ve already tried things like export RUST_BACKTRACE=full && dfx start.

4 Likes
2

I had the same kind of errors (albeit a bit more explicit) when trying to use time, apparently that’s not implemented in wasm.

As for debugging, the old trusty print from time to time helped me along the way:

    ic_cdk::println!("IN");
    [...]
    ic_cdk::println!("OUT");
2 Likes
3

My code is extremely simple, and unfortunately the panic is somewhere within my dependencies (I’m calling 1 function in the code that panics). A stack trace would probably instantly point out where the issue is, using ic_cdk::println won’t help me because I already know exactly where the problem is in my source code, just not where it’s coming from within the dependency.

4

Ah, gotcha! That makes sense. Perhaps the dependencies that you include are using libc? I remember a talk by Irina Shestak where she talked about choosing dependencies that either don’t use libc, or that you can configure not to include libc (a.k.a wasm compatible). Check it out, maybe?

5

Figured it out! I would still like to know how to enable backtraces, but I cloned my dependency (proptest), used some ic_cdk::println statements like you suggested, and tracked it down to some unnecessary OS environment variable configurations. I just commented that code out. So I’ll need to rely on my local version, fork proptest, or do a pull request and see if the environment variables functionality can be feature-gaited or something.

1 Like