search

gtk-rs / gtk3-rs

Rust bindings for GTK 3
https://gtk-rs.org
MIT License
508 stars 90 forks source link

Creating ApplicationWindow in main causes segfault #84

Open ColonelThirtyTwo opened 3 years ago

ColonelThirtyTwo commented 3 years ago

Dumb program that doesn't work cuz I forgot how to use gtk the right way (ie the activate signal):


use gio::prelude::*;
use gtk::prelude::*;
use std::env::args;

fn main() {
    let app = gtk::Application::new(None, gio::ApplicationFlags::default()).unwrap();
    gtk::ApplicationWindow::new(&app).show();
    app.run(&args().collect::<Vec<_>>());
}

The gtk::ApplicationWindow::new call causes a segfault though, in the g_object_new call of gtk::application_window::<impl gtk::auto::application_window::ApplicationWindow>::new

Versions are:

gio = "0.9.1"
glib = "0.10.2"
gtk = "0.9.2"

No feature flags for the versions.

GuillaumeGomez commented 3 years ago

I wonder if there is a way to prevent people to use this function outside of the signal...

sdroege commented 3 years ago

Why does it segfault though? Can you provide a backtrace of the crash and any critical warnings that are printed?

ColonelThirtyTwo commented 3 years ago 
(process:17313): Gtk-CRITICAL **: 11:13:01.922: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(process:17313): Gtk-CRITICAL **: 11:13:01.924: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

(process:17313): Gtk-CRITICAL **: 11:13:01.924: _gtk_style_provider_private_get_settings: assertion 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff78e0c1c in ?? () from /usr/lib/libgtk-3.so.0
(gdb) bt
#0  0x00007ffff78e0c1c in  () at /usr/lib/libgtk-3.so.0
gtk-rs/gtk#1  0x00007ffff7900d5c in  () at /usr/lib/libgtk-3.so.0
gtk-rs/gtk#2  0x00007ffff78eb2f5 in  () at /usr/lib/libgtk-3.so.0
gtk-rs/gtk#3  0x00007ffff73397e7 in g_type_create_instance () at /usr/lib/libgobject-2.0.so.0
gtk-rs/gtk#4  0x00007ffff7329ffe in  () at /usr/lib/libgobject-2.0.so.0
gtk-rs/gtk#5  0x00007ffff732b13d in g_object_new_with_properties () at /usr/lib/libgobject-2.0.so.0
gtk-rs/gtk#6  0x00007ffff732bc42 in g_object_new () at /usr/lib/libgobject-2.0.so.0
gtk-rs/gtk#7  0x00007ffff7b05df3 in  () at /usr/lib/libgtk-3.so.0
gtk-rs/gtk#8  0x00007ffff73397e7 in g_type_create_instance () at /usr/lib/libgobject-2.0.so.0
gtk-rs/gtk#9  0x00007ffff7329ffe in  () at /usr/lib/libgobject-2.0.so.0
gtk-rs/gtk#10 0x00007ffff732b8a4 in g_object_new_valist () at /usr/lib/libgobject-2.0.so.0
gtk-rs/gtk#11 0x00007ffff732bc1a in g_object_new () at /usr/lib/libgobject-2.0.so.0
gtk-rs/gtk#12 0x000055555555cd31 in gtk::application_window::<impl gtk::auto::application_window::ApplicationWindow>::new (application=0x7fffffffdeb0)
    at /home/col/.cargo/registry/src/github.com-1ecc6299db9ec823/gtk-0.9.2/src/application_window.rs:13
gtk-rs/gtk#13 0x000055555555d56a in window::main () at examples/window.rs:8
sdroege commented 3 years ago

Not sure what we can do here from our side. That looks like something that can only be caught easily inside GTK, but they will probably say that you just shouldn't do this.

On the bindings side we could remember via TLS if we're currently inside the GtkApplication but that also won't be reliable as nothing prevents the application code to not go via the bindings for this...

dkl commented 3 years ago

The crash happens with plain C too: https://gitlab.gnome.org/GNOME/gtk/-/issues/3310

sdroege commented 3 years ago

Yeah, as expected and the response is also as expected :) See my comment above.

In a perfect world we would set G_DEBUG=fatal_criticals in all Rust applications to simply abort the process at that time, but that's unfortunately not possible with GTK applications because they abuse critical warnings for things that are not very critical.