Panicked at 'Failed to serialize message: ErrorImpl { code: Message("The number can't be stored in CBOR"), offset: 0 }', /build/rs/canister_sandbox/common/src/transport.rs:285:55

Developers
1

Since the dfinity/ic repo doesn’t allow reporting bugs I’ll do it here.

It seems that the Canister sandbox uses cbor_serde and CBOR for its transportation layer, and some of the messages (didn’t track down which ones actually) have a i128 or u128 type in in, which, if flowing over 64 bits, causes cbor_serde to panic (upstream bug). Not sure if that would stall a subnet.

I triggered this with Motoko and drun, but I assume it can at least be triggered in a dev instance of the replica. Triggering it in the wild may require amassing 2^64 cycles in one canister, which is a bit expensive to demonstrate a bug.

See https://github.com/dfinity/motoko/pull/3105/files for a reproducer.

Pinging @hcb.

5 Likes
2

BTW, looks like cbor_serde is no longer maintained by upstream: https://github.com/pyfisch/cbor. It recommends two other libraries. And https://crates.io/crates/ciborium at least get CBOR numbers right (always encodes at smallest size)

1 Like
3

Thanks, Joachim… I’ll escalate this to make sure peoples see it.

1 Like
4

Great catch @nomeata! We are discussing different options on how to fix this with @hcb. We’ll post an update when we have a fix.

2 Likes
5

Sorry for the delay. We are switching to bincode that not only supports u128/i128 but also improves performance.

2 Likes
6

@ulan , can you ping me here when this lands?

7

Sorry, forgot to update this thread.

The change was merged on Feb 23: https://github.com/dfinity/ic/commit/45b340ab31bb3603d60cfdd8e9f6b6b68cfea367

It should be in the latest SDK releases: 0.9.3-beta.1 and 0.9.3-beta.0

4 Likes