Panic when invoking cargo valgrind

[thedrow]

I have a project which uses rust-bindgen.
It seems like it is not supported by this command somehow.
In any case, panicking does not count as a clear error that indicates what's wrong and how to fix it.

RUST_BACKTRACE=full cargo valgrind
thread 'main' panicked at 'not yet implemented', /home/omer/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-valgrind-1.2.0/src/lib.rs:641:83
stack backtrace:
   0:     0x55cdadef1474 - backtrace::backtrace::libunwind::trace::h4dc2f373699fbe93
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
   1:     0x55cdadef1474 - backtrace::backtrace::trace_unsynchronized::h7b04f002610ccc35
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
   2:     0x55cdadef1474 - std::sys_common::backtrace::_print_fmt::h0238c0a72ffc5be3
                               at src/libstd/sys_common/backtrace.rs:76
   3:     0x55cdadef1474 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h40ab018276d013f4
                               at src/libstd/sys_common/backtrace.rs:60
   4:     0x55cdadf156dc - core::fmt::write::h029a8d927db7b721
                               at src/libcore/fmt/mod.rs:1030
   5:     0x55cdadeed807 - std::io::Write::write_fmt::ha386135dc33cd74f
                               at src/libstd/io/mod.rs:1412
   6:     0x55cdadef3855 - std::sys_common::backtrace::_print::he925af2d0a3180ad
                               at src/libstd/sys_common/backtrace.rs:64
   7:     0x55cdadef3855 - std::sys_common::backtrace::print::ha41b6194bcf8f6ce
                               at src/libstd/sys_common/backtrace.rs:49
   8:     0x55cdadef3855 - std::panicking::default_hook::{{closure}}::h659784bc3ca43626
                               at src/libstd/panicking.rs:196
   9:     0x55cdadef3546 - std::panicking::default_hook::h2f638ec54806c9d8
                               at src/libstd/panicking.rs:210
  10:     0x55cdadef3ef5 - std::panicking::rust_panic_with_hook::h12d7650e86d2fcb0
                               at src/libstd/panicking.rs:473
  11:     0x55cdade67625 - std::panicking::begin_panic::h1bc0c6165771a9ad
  12:     0x55cdade4af80 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once::h03ba4698face0b56
  13:     0x55cdade57107 - <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::next::he09a78cc682c470e
  14:     0x55cdade53eb4 - <core::iter::adapters::flatten::FlatMap<I,U,F> as core::iter::traits::iterator::Iterator>::next::h27e593f28491c9f6
  15:     0x55cdade56811 - <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter::h36558778d1bacfb3
  16:     0x55cdade4a113 - cargo_valgrind::targets::hbd7da8ddd042f593
  17:     0x55cdade6b7d8 - cargo_valgrind::run::hb5ac550d958cc5e7
  18:     0x55cdade6e3d2 - cargo_valgrind::main::h66226763dd24eedb
  19:     0x55cdade50943 - std::rt::lang_start::{{closure}}::h06707b789db1cb0c
  20:     0x55cdadef3923 - std::rt::lang_start_internal::{{closure}}::h1e233f1ef686736e
                               at src/libstd/rt.rs:49
  21:     0x55cdadef3923 - std::panicking::try::do_call::h0eae6d7a87b4dd98
                               at src/libstd/panicking.rs:292
  22:     0x55cdadefa66a - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:80
  23:     0x55cdadef43ed - std::panicking::try::h496030de30818333
                               at src/libstd/panicking.rs:271
  24:     0x55cdadef43ed - std::panic::catch_unwind::h9f715533e260dcba
                               at src/libstd/panic.rs:394
  25:     0x55cdadef43ed - std::rt::lang_start_internal::h8832b9e1d5618fb5
                               at src/libstd/rt.rs:48
  26:     0x55cdade6e532 - main
  27:     0x7f0571ed8b97 - __libc_start_main
  28:     0x55cdade3f16a - _start
  29:                0x0 - <unknown

[jfrimmel]

Hello,
thank you for the report. It seems, that the parsing of the cargo metadata is not implemented correctly for crates which have a custom build script. I'll investigate this further and hope, that I'll fix this soon.

[jfrimmel]

Hello @thedrow,

can you please give feedback, whether the panic is resolved? If not, feel free to comment or re-open this issue.

Edit: note, that you'll have to use the latest version from GitHub, since I haven't uploaded it to crates.io yet. See the 2nd installation variant.

[thedrow]

It still panics for me.
I do have an integration test though.

Custom build scripts are pretty common with C libraries, aren't they?
Why shouldn't we support them?
Perhaps we should open a new issue about that.

[jfrimmel]

Okay, I think this is due to the use of the integration test, that is not yet supported in cargo valgrind.
The build scripts itself can now be used.
I'll open a new issue about this and try to address this very soon.

[jfrimmel]

@thedrow As per #24 I added support for integration tests. You should now be able to run your project using cargo valgrind. Again install the latest version from GitHub to test it.

Please report, if it worked.

[thedrow]

Yes, that works wonderfully!