Skip to content
This repository has been archived by the owner on Mar 4, 2024. It is now read-only.

Creating ApplicationWindow in main causes segfault #84

Open
ColonelThirtyTwo opened this issue Oct 16, 2020 · 6 comments
Open

Creating ApplicationWindow in main causes segfault #84

ColonelThirtyTwo opened this issue Oct 16, 2020 · 6 comments
Labels
bug Something isn't working gtk

Comments

@ColonelThirtyTwo
Copy link

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
Copy link
Member

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

@sdroege
Copy link
Member

sdroege commented Oct 16, 2020

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

@ColonelThirtyTwo
Copy link
Author

(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
Copy link
Member

sdroege commented Oct 30, 2020

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
Copy link

dkl commented Oct 31, 2020

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

@sdroege
Copy link
Member

sdroege commented Oct 31, 2020

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.

@bilelmoussaoui bilelmoussaoui transferred this issue from gtk-rs/gtk Nov 10, 2020
@sdroege sdroege added the bug Something isn't working label Nov 10, 2020
elmarco pushed a commit to elmarco/gtk-rs that referenced this issue Feb 10, 2021
…cus-child

gtk: fix widget's set_focus_child implementation
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working gtk
Projects
None yet
Development

No branches or pull requests

5 participants