subclass::object::tests: error: process didn't exit successfully on nightly and beta

[fengalin]

Version	Status
1.36.0-stable	OK except for Wndows 32bits
1.37.0-stable	OK except for Wndows 32bits (probably)
1.38.0-beta	KO
2019-08-09 nightly	KO

Already present before the changes with Value::get return type. Can be reproduced at commit 9cf3eeb

cargo +nightly test subclass::object::test::test_signal_return_wrong_type --features subclassing

Here is a backtrace:

thread 'subclass::object::test::test_signal_return_wrong_type' panicked at 'Signal required return value of type gchararray but got gboolean', src/object.rs:1326:29
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.34/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:214
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
   7: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:384
   8: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:339
   9: <T as glib::object::ObjectExt>::connect_unsafe::{{closure}}
             at src/object.rs:1326
  10: <alloc::boxed::Box<F> as core::ops::function::Fn<A>>::call
             at /rustc/00ee1b47f42129a0a6e33510578fbcf07c1e5382/src/liballoc/boxed.rs:801
  11: glib::closure::Closure::new_unsafe::marshal
             at src/closure.rs:51
  12: g_closure_invoke
  13: <unknown>
  14: g_signal_emitv
  15: <T as glib::object::ObjectExt>::emit
             at src/object.rs:1432
  16: glib::subclass::object::test::test_signal_return_wrong_type
             at src/subclass/object.rs:667
  17: glib::subclass::object::test::test_signal_return_wrong_type::{{closure}}
             at src/subclass/object.rs:659
  18: core::ops::function::FnOnce::call_once
             at /rustc/00ee1b47f42129a0a6e33510578fbcf07c1e5382/src/libcore/ops/function.rs:235
  19: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/00ee1b47f42129a0a6e33510578fbcf07c1e5382/src/liballoc/boxed.rs:787
  20: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  21: std::panicking::try
             at /rustc/00ee1b47f42129a0a6e33510578fbcf07c1e5382/src/libstd/panicking.rs:275
  22: std::panic::catch_unwind
             at /rustc/00ee1b47f42129a0a6e33510578fbcf07c1e5382/src/libstd/panic.rs:394
  23: test::run_test::run_test_inner::{{closure}}
             at src/libtest/lib.rs:1408
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: process didn't exit successfully: `[...]/glib/target/debug/deps/glib-197ec9b63ab58d0c 'subclass::object::test::test_signal_return_wrong_type' --nocapture` (signal: 4, SIGILL: illegal instruction)

It seems to be related to the panic occurring in a signal's closure (remember it doesn't happen in stable 1.36.0 & 1.37.0).

Anything happened WRT panic handlers post rustc-1.37.0?

[sdroege]

Panics across FFI boundaries are again undefined behaviour, so this is expected to fail randomly. See rust-lang/rust#58794

It was a simple abort in a few releases and we depended on that, then it turned out that some broken crates are abusing the undefined behaviour and it was reverted, leaving us with problematic code.

[sdroege]

Said differently, we can't have any tests right now that panic until this is fixed in the compiler.

[fengalin]

Ok, thanks for the pointer.

Said differently, we can't have any tests right now that panic until this is fixed in the compiler.

Shall I comment them out then?

Edit: answered myself: will comment them out! :)

[sdroege]

Even after this is fixed in Rust, they won't work properly. Instead of being able to catch the panic the process would just be aborted. You can just remove them, I guess

[sdroege]

Let's close this then