Thread panicks when filter is used inside C code about gst-plugin-rs HOT 9 CLOSED

Thanks for the report. This is indeed supposed to be possible. gst-launch-1.0 is not doing anything different than what your code is doing. Which makes it even more mysterious why it is failing with your code.

Basically the problem here is that the plugin pointer here is not a GstPlugin:

Maybe it is NULL, maybe something completely different. It really shouldn't though.

Can you add this at the top of the function and give the output before it panics?

println!("{:?}", plugin);
let type_ = from_glib(*(plugin as *const *const glib_sys::GType));
println!("{:?}", type_);

from gst-plugin-rs.

update: The problem is on my side (since I've managed to create an rsaudioecho element on Linux host, but not on the mac); sorry for worrying.

So, I think it's OK to close this issue.

It was confusing to be able to use the custom plugins with rust, and failing with C; but at the same time gst-launch manages to find them fine. The thoughts below are just FYI.

I have managed to compile it with

unsafe extern "C" fn plugin_init_trampoline(plugin: *mut $crate::gst_ffi::GstPlugin) -> $crate::glib_ffi::gboolean {
    println!("{:?}", plugin);
    let type_: Type = from_glib((*(plugin as *const *const $crate::glib_ffi::GType)) as $crate::glib_ffi::GType);
    println!("{:?}", type_);
    super::$plugin_init(&from_glib_borrow(plugin)).to_glib()
}

Sidenote:

Without as GType cast, it fails to compile with an error the trait glib::translate::FromGlib<*const usize> is not implemented for...

so I have found possible types in FromGlib crate docs and cast it to u32 (not sure if it is correct)

... and got

0x102804180
thread '<unnamed>' panicked at 'assertion failed: !ptr.is_null()', /Users/username/.cargo/git/checkouts/glib-928cf7b282977403/a51dc67/src/translate.rs:855:8
stack backtrace:
   0: std::sys::imp::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: <alloc::string::String as glib::translate::FromGlibPtrNone<*const i8>>::from_glib_none
   7: glib::translate::from_glib_none
   8: glib::types::Type::name
   9: <glib::types::Type as core::fmt::Debug>::fmt
  10: core::fmt::write
  11: <std::io::stdio::Stdout as std::io::Write>::write_fmt
  12: std::io::stdio::_print
  13: gstrsaudiofx::plugin_desc::plugin_init_trampoline
  14: gst_plugin_register_func
  15: _priv_gst_plugin_load_file_for_registry
  16: exchange_packets
  17: _gst_plugin_loader_client_run
  18: main
fatal runtime error: failed to initiate panic, error 5

Therefore, I guess it is NULL for some reason;

from gst-plugin-rs.

If it works on Linux but not on macOS, that's definitely a bug and one that has to be solved. Unfortunately I don't have access to a macOS machine myself currently (mine is waiting in a box somewhere to be set up again). I'll have to find remote access to one, or so :)

Thanks for the added output and sorry for missing that conversion is needed. That's unfortunately not too helpful either, it basically means that we get some random pointer there as plugin. It's not NULL but it's also no pointer to any GObject.

@qezz Do you maybe have multiple versions of GObject on your system, and your C application, GStreamer and/or the Rust plugin are linking to different ones?

from gst-plugin-rs.

@qezz How did you install GStreamer btw, and do you have multiple installations on your system (e.g. homebrew and from the GStreamer binaries)?

from gst-plugin-rs.

I installed GStreamer 1.12.3 from homebrew and gst-plugin-rs from master, just running cargo build. Then I added includes for stdlib.h and gst/gst.h to the program in the first post and built it with clang -o issue23 issue23.c -Wall -O0 -g $(pkg-config --cflags --libs gstreamer-1.0).

On macOS 10.13.1 (17B48), Xcode Version 9.1 (9B55), clang Apple LLVM version 9.0.0 (clang-900.0.38), GStreamer 1.12.3 from homebrew, cargo 0.22.0 (3423351a5 2017-10-06), rustc 1.21.0 (3b72af97e 2017-10-09).

from gst-plugin-rs.

Oh, and: setenv("GST_PLUGIN_PATH","/Users/robertsw/src/gst-plugin-rs/target/debug",1); - I pointed GST_PLUGIN_PATH explicitly to where the .dylib files are.

from gst-plugin-rs.

@qezz Maybe you can also run otool -L on a) the plugin (libgstrsaudiofx.dylib), and b) your application, and paste the output of both here?

from gst-plugin-rs.

do you have multiple installations on your system

There is some mess with Gstreamer development package for mac, so yes, I definitely have.

However, both versions are 1.12.3

otool

# rust plugin
$ otool -L target/debug/libgstrsaudiofx.dylib
target/debug/libgstrsaudiofx.dylib:
	/Users/username/sources/gstreamer/gst-plugin-rs/target/debug/deps/libgstrsaudiofx.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/local/opt/gst-plugins-base/lib/libgstaudio-1.0.0.dylib (compatibility version 1204.0.0, current version 1204.0.0)
	/usr/local/opt/gstreamer/lib/libgstbase-1.0.0.dylib (compatibility version 1204.0.0, current version 1204.0.0)
	/usr/local/opt/gstreamer/lib/libgstreamer-1.0.0.dylib (compatibility version 1204.0.0, current version 1204.0.0)
	/usr/local/opt/glib/lib/libgobject-2.0.0.dylib (compatibility version 5401.0.0, current version 5401.1.0)
	/usr/local/opt/glib/lib/libglib-2.0.0.dylib (compatibility version 5401.0.0, current version 5401.1.0)
	/usr/local/opt/gettext/lib/libintl.8.dylib (compatibility version 10.0.0, current version 10.5.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

# app
$ otool -L GStCxxDynPipe
GStCxxDynPipe:
	/Library/Frameworks/GStreamer.framework/Versions/1.0/lib/GStreamer (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 307.5.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2)

Does it mean that I have two different versions linked?

If yes, then I'm about to purge gstreamer and glib from the system, and install them again

from gst-plugin-rs.

Yes, it's using different versions. GStCxxDynPipe uses the GStreamer binaries, libgstrsaudiofx.dylib uses the Homebrew binaries. If you load both in the same process, things will fall apart :)

You can keep both versions around, but it's dangerous and this might happen again. The only thing you need to do is to make sure that you use the same PKG_CONFIG_PATH for building the plugin as for your application (so that it links/uses the same GStreamer).

from gst-plugin-rs.