twiggy crashes with mono binaries

[kumpera]

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.jparrowsec.cn-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

[fitzgen]

Thanks for the bug report!

Are there >= 2^32 - 1 elements entries in that wasm?? o_O That is quite an achievement!

[kumpera]

That sounds unlikely, it's a 6mb binary.

[fitzgen]

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

[fitzgen]

I have a fix locally, cleaning it up. Thanks again for the bug report @kumpera!

[kumpera]

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.

[fitzgen]

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! :)