twiggy crashes with mono binaries
kumpera opened this issue · 6 comments
Hello,
I'm trying to use twiggy 0.2.0 with mono's wasm port and hitting this crash on OSX:
tijuca:wasm rokumper$ RUST_BACKTRACE=1 twiggy top debug/mono.wasm
thread 'main' panicked at 'assertion failed: index < u32::MAX as usize', /Users/kumpera/.cargo/registry/src/github.com-1ecc6299db9ec823/twiggy-ir-0.2.0/./ir.rs:414:9
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::begin_panic
6: twiggy_ir::Id::entry
7: twiggy_parser::wasm::<impl twiggy_parser::Parse<'a> for parity_wasm::elements::section::ElementSection>::parse_edges
8: twiggy_parser::wasm::<impl twiggy_parser::Parse<'a> for parity_wasm::elements::module::Module>::parse_edges
9: twiggy_parser::parse_wasm
10: twiggy_parser::read_and_parse
11: twiggy::main
12: std::rt::lang_start::{{closure}}
13: std::panicking::try::do_call
14: __rust_maybe_catch_panic
15: std::rt::lang_start_internal
16: main
To reproduce it. Download this file: https://jenkins.mono-project.com/job/test-mono-mainline-wasm/926/label=ubuntu-1804-amd64/Azure/processDownloadRequest/926/ubuntu-1804-amd64/sdks/wasm/mono-wasm-24c1f2a40c1.zip
Then run twiggy: twiggy top debug/mono.wasm
Thanks for the bug report!
Are there >= 2^32 - 1 elements entries in that wasm?? o_O That is quite an achievement!
That sounds unlikely, it's a 6mb binary.
On master I get a slightly different panic:
$ RUST_BACKTRACE=1 cargo run -- top mono.wasm
Finished dev [unoptimized + debuginfo] target(s) in 0.06s
Running `target/debug/twiggy top mono.wasm`
thread 'main' panicked at 'attempt to subtract with overflow', parser/wasm_parse/mod.rs:564:52
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:475
5: std::panicking::continue_panic_fmt
at libstd/panicking.rs:390
6: rust_begin_unwind
at libstd/panicking.rs:325
7: core::panicking::panic_fmt
at libcore/panicking.rs:77
8: core::panicking::panic
at libcore/panicking.rs:52
9: twiggy_parser::wasm_parse::<impl twiggy_parser::Parse<'a> for parity_wasm::elements::section::ElementSection>::parse_edges
at parser/wasm_parse/mod.rs:564
10: twiggy_parser::wasm_parse::<impl twiggy_parser::Parse<'a> for parity_wasm::elements::module::Module>::parse_edges
at parser/wasm_parse/mod.rs:147
11: twiggy_parser::parse_wasm
at parser/./parser.rs:84
12: twiggy_parser::read_and_parse
at ./parser/./parser.rs:36
13: twiggy::run
at twiggy/./twiggy.rs:30
14: twiggy::main
at twiggy/./twiggy.rs:20
15: std::rt::lang_start::{{closure}}
at /checkout/src/libstd/rt.rs:74
16: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:310
17: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102
18: std::rt::lang_start_internal
at libstd/panicking.rs:289
at libstd/panic.rs:392
at libstd/rt.rs:58
19: std::rt::lang_start
at /checkout/src/libstd/rt.rs:74
20: main
21: __libc_start_main
22: _start
Thank you so much for looking into this.
I hope my team can join in helping twiggy to be the go-to tool for analyzing wasm binaries.
Fix is over at #152
I hope my team can join in helping twiggy to be the go-to tool for analyzing wasm binaries.
Great to hear this! I think the best thing you could do for now is just use twiggy as much as possible, file bugs when you hit them, request missing features that you end up needing, etc! There are a relatively small number of folks using twiggy right now, so more real world usage would be very helpful! :)