Starting a second instance crashes the first instance

[ysbaddaden]

Gtk tries to keep unique applications by default. When starting a new instance it will actually send a message to the currently running instance, and immediately exit the new instance.

This is currently not supported by the app, and is leading to a crash:

At a minimum, the app shouldn't crash. Ideally, it should be un-minimized (if needed), moved to the current screen (if possible) and put above any existing windows on that screen.

[ysbaddaden]

~/work/manastech/brium $ brium

(brium:15304): Gtk-CRITICAL **: 10:10:59.790: gtk_widget_set_parent: assertion 'GTK_IS_WIDGET (widget)' failed

(brium:15304): Gtk-CRITICAL **: 10:10:59.790: gtk_widget_get_style_context: assertion 'GTK_IS_WIDGET (widget)' failed

(brium:15304): Gtk-CRITICAL **: 10:10:59.790: gtk_style_context_add_class: assertion 'GTK_IS_STYLE_CONTEXT (context)' failed

(brium:15304): Gtk-CRITICAL **: 10:10:59.790: gtk_widget_get_parent: assertion 'GTK_IS_WIDGET (widget)' failed

(brium:15304): Gtk-CRITICAL **: 10:10:59.790: gtk_widget_freeze_child_notify: assertion 'GTK_IS_WIDGET (widget)' failed

(brium:15304): Gtk-CRITICAL **: 10:10:59.790: gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(brium:15304): GLib-GObject-CRITICAL **: 10:10:59.790: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
Invalid memory access (signal 11) at address 0xb8
[0x55a122d595e6] ?? +94150562518502 in brium
[0x55a122d595ad] ?? +94150562518445 in brium
[0x7f742aeed420] ?? +140136913228832 in /lib/x86_64-linux-gnu/libpthread.so.0
[0x7f742b46ffd0] ?? +140136919007184 in /lib/x86_64-linux-gnu/libgtk-3.so.0
[0x7f742b4ea036] ?? +140136919506998 in /lib/x86_64-linux-gnu/libgtk-3.so.0
[0x55a122da1022] ?? +94150562811938 in brium
[0x7f742b0ae802] g_closure_invoke +434 in /lib/x86_64-linux-gnu/libgobject-2.0.so.0
[0x7f742b0c2814] ?? +140136915150868 in /lib/x86_64-linux-gnu/libgobject-2.0.so.0
[0x7f742b0cdbbe] g_signal_emit_valist +4270 in /lib/x86_64-linux-gnu/libgobject-2.0.so.0
[0x7f742b0ceb9c] g_signal_emit_by_name +2700 in /lib/x86_64-linux-gnu/libgobject-2.0.so.0
[0x7f742b1df13d] ?? +140136916316477 in /lib/x86_64-linux-gnu/libgio-2.0.so.0
[0x7f742b208a24] ?? +140136916486692 in /lib/x86_64-linux-gnu/libgio-2.0.so.0
[0x7f742afc104e] g_main_context_dispatch +334 in /lib/x86_64-linux-gnu/libglib-2.0.so.0
[0x7f742afc1400] ?? +140136914097152 in /lib/x86_64-linux-gnu/libglib-2.0.so.0
[0x7f742afc14a3] g_main_context_iteration +51 in /lib/x86_64-linux-gnu/libglib-2.0.so.0
[0x7f742b1dcfe5] g_application_run +517 in /lib/x86_64-linux-gnu/libgio-2.0.so.0
[0x55a122d15002] __crystal_main +16498 in brium
[0x55a122d1b491] main +65 in brium
[0x7f742ac8d083] __libc_start_main +243 in /lib/x86_64-linux-gnu/libc.so.6
[0x55a122d10ece] _start +46 in brium
[0x0] ???

[ysbaddaden]

The stack trace looks like we're trying to build the UI again, thus replacing some GObjects references, the GC collects the older (but still active) references, and we end up with a segfault.

[ysbaddaden]

Confirmed: Gtk signals the running application which runs the activate signal handler again. With a simple check we can differentiate between the app is starting up, and another instance tried to be started.

Now, to understand how to switch to the running app...

[ysbaddaden]

Found it: gtk_window_present_with_time.

[ysbaddaden]

Done in c0feda7

[ysbaddaden]

Oh, g_present_with_time isn't enough, the window/entry needs to grab focus!