Closed jstarry closed 5 years ago
Thanks, Justin, great information! Both cases look similar like there is a jump outside of the program. The crash scenario looks like an overflow because the pc is so large.
Looks like original vm didn't expect large programs and so jump calculations were done with i16 types. The following pull request fixes the issue:
https://github.com/solana-labs/rbpf/pull/34
I will close the issue once Solana picks up the latest solana_rbpf.
The use case that identified this issue was the use of serde_json in bpf programs. serde_json is huge (pulling in 1serde_json::from_slice1` increases the elf size by ~400k. This led to very large programs that included jumps exceeding 32k. serde_json is probably not the best choice for on-chain programs.
Sounds great, thanks for investigating! Agreed about serde_json
not being a good choice. In the future it would be great to have a low-cost solution for serializing data!
Fixed in #5609
Problem
I encountered a panic while using a modified
serde_json
crate to serialize aVec
into account data. Without modifications to the bpf vm, the panic doesn't crash the node. However, if I increase the max call depth of the VM, the node fully crashes when the panic occurs. You can see from the two stacktraces below that the panics are different. Happy to split this into 2 separate issues if necessary!Recoverable Panic Repro
rbpf-panic
branch in https://github.com/solana-labs/example-messagefeednpm install && npm run build:bpf-rust
npm run localnet:update && npm run localnet:up
npm run start-server
** Note that the bpf program is really big so it takes awhile to load.
Node Crash Panic Repro
solana-rbpf
, I bumped from10
to50
hereEnv
rustc 1.36.0
Recoverable panic log
Node crash log