crash running example

[progman1]

hello,

In starting methol without a ctf file argument this is printed:

021-10-07T04:33:15.136Z WARN  charts::data::watcher > running on legacy memthol dump format
 2021-10-07T04:33:15.136Z WARN  charts::data::watcher > this will probably not work with this version of memthol
 2021-10-07T04:33:15.136Z WARN  charts::data::watcher > unless the diffs must verify the following invariant:
 2021-10-07T04:33:15.136Z WARN  charts::data::watcher > - allocations appear ordered by allocation UID
 2021-10-07T04:33:15.136Z WARN  charts::data::watcher > - no allocation UID is skipped
 2021-10-07T04:33:15.136Z WARN  charts::data::watcher > meaning successive UIDs `uid_i` and `uid_j` must be such that `uid_j == uid_i + 1`

this is from a new build from the repo.
is it relevant to:?:

RUST_BACKTRACE=full ./memthol/memthol rsc/dumps/ctf/mini_ae.ctf 

rsc/dumps/ctf/mini_ae.ctf 
|===| Starting
| url: http://localhost:7878
| target: `rsc/dumps/ctf/mini_ae.ctf`
|===|

thread '<unnamed>' panicked at '[fatal] while converting 281215689031858 (ctf location parser: encoded): out of range integral type conversion attempted', /home/dev/deps/memthol/libs/base/src/lib.rs:59:19
stack backtrace:
   0:   0x8a5824 - std::backtrace_rs::backtrace::libunwind::trace::h3e34b0a0eff705af
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:   0x8a5824 - std::backtrace_rs::backtrace::trace_unsynchronized::hf6114550de563c5e
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:   0x8a5824 - std::sys_common::backtrace::_print_fmt::h69ae9391fae52d7d
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/sys_common/backtrace.rs:67:5
   3:   0x8a5824 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h32fc182ca31b20f7
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/sys_common/backtrace.rs:46:22
   4:   0x707d40 - core::fmt::write::hca5213f5dd97a3f1
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/core/src/fmt/mod.rs:1162:17
   5:   0x8a4584 - std::io::Write::write_fmt::hf491986efcc99fdb
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/io/mod.rs:1684:15
   6:   0x8a4c5c - std::sys_common::backtrace::_print::hf12de2ca92425fa7
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/sys_common/backtrace.rs:49:5
   7:   0x8a4c5c - std::sys_common::backtrace::print::h3494c0109615e65d
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/sys_common/backtrace.rs:36:9
   8:   0x8a4c5c - std::panicking::default_hook::{{closure}}::h4f04e440b92fc577
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/panicking.rs:210:50
   9:   0x8a40fc - std::panicking::default_hook::hb88b6bb58f7c809b
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/panicking.rs:227:9
  10:   0x8a40fc - std::panicking::rust_panic_with_hook::hbc91bf8a19c34ba8
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/panicking.rs:624:17
  11:   0x8c6074 - std::panicking::begin_panic_handler::{{closure}}::h279876c7adfe1e17
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/panicking.rs:521:13
  12:   0x8c5fd8 - std::sys_common::backtrace::__rust_end_short_backtrace::h54f91957c54178e6
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/sys_common/backtrace.rs:141:18
  13:   0x8c5f9c - rust_begin_unwind
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/panicking.rs:517:5
  14:   0x8c5f70 - std::panicking::begin_panic_fmt::hc7d4863163ca693a
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/panicking.rs:460:5
  15:   0x7b6e94 - ctf::parse::PacketParser<Endian>::next_event::hce7dc6ea245f48c4
  16:   0x816af0 - ctf::diff_parse::parse::h881a56728eb0a221
  17:   0x7bf3a4 - charts::data::watcher::Watcher::ctf_run::h5256ebcf28b6e7a6
  18:   0x821a30 - std::sys_common::backtrace::__rust_begin_short_backtrace::h4abef283aba66d11
  19:   0x7aaad4 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hc5a6cb6f13771fce
  20:   0x8d49ec - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h88c66aa10027a380
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/alloc/src/boxed.rs:1638:9
  21:   0x8d49ec - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h043a83ad1dc54ca3
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/alloc/src/boxed.rs:1638:9
  22:   0x8d49ec - std::sys::unix::thread::Thread::new::thread_start::hb2a3ee694df970a8
                       at /rustc/25ec8273855fde2d72ae877b397e054de5300e10/library/std/src/sys/unix/thread.rs:106:17

this happens under both build and release builds on an arm7l debian platform.
thanks.

[AdrienChampion]

Thank you for your bug report :)

Sorry it took so long to get back to you. As you might have noticed the repo is flagged for security vulnerabilities, which is due to very outdated dependencies. Which lead me to trying to fix that which lead me to this issue again.

I'm not completely sure what the exact cause of your problem is, but as I was trying to update the dependencies I became aware of how much the wasm-related Rust ecosystem has changed. I would guess that's what causes your problems.

Regardless, we would have to first update everything before trying to (ask you to) reproduce the issue you ran into. It's not clear at this point if/when we will do that. We developed memthol to see if we could generate traction and maintain/update it. As far as we are aware there is virtually no users, so it's hard for us to decide to spend time diving in the new wasm workflow and updating everything.

Let me know if you would still be interested in memthol, and perhaps more importantly why so that I can assess whether fixing the current version of memthol is worth it for you (and us).