1244305 - [GIO 2.46 regression] Crash when trying to open file with non-default application using GTK application chooser

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect)

Description

[Milan Bouchet-Valat]

This bug was filed from the Socorro interface and is 
report bp-41eab1da-7a64-4e5b-beaf-0914a2160129.
=============================================================

Many reports similar to mine mention a crash when trying to open a downloaded file using a non-default application, i.e. when using the GTK application chooser. I've seen in with Firefox 43, but some reports are about Firefox 47.

Comment 1

[Francis Herne]

This occurs for me with Firefox 43 and 44, on Arch Linux.

It's completely reproducible, every attempt to use a non-default application results in a crash.

Comment 2

[Loic]

Francis, could you run the tool mozregressin to find a regression range in FF43, please.
See http://mozilla.github.io/mozregression/ for details.

Comment 3

[Milan Bouchet-Valat]

If I'm correct, this is a new feature introduced in a recent version of Firefox (maybe 43?). Before that, that GTK dialog wasn't used at all. So its author should know pretty well when the feature and the crash were introduced.

Comment 4

[:Gijs (he/him)]

(In reply to Milan Bouchet-Valat from comment #3)
> If I'm correct, this is a new feature introduced in a recent version of
> Firefox (maybe 43?). Before that, that GTK dialog wasn't used at all. So its
> author should know pretty well when the feature and the crash were
> introduced.

Can you reproduce the crash with an official build so it produces a usable stack trace (and to ensure what you're seeing isn't an artifact of Arch being Arch...)?

Comment 5

[:Gijs (he/him)]

It seems bug 1129873 changed this in 41, not 43, and we haven't switched to gtk3 by default yet, so no idea what's going on there or why it would be new in 43, unless Arch overrides our defaults and builds against gtk3 instead of gtk2...

Comment 6

[Francis Herne]

Arch does, is that not why this bug is flagged to block gtk3?

Anyway, I can reproduce with the official nightly build 47.0a1 (also now built against gtk3).

Stderr output:
[Child 1815] ###!!! ABORT: Aborting on channel error.: file /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/glue/MessageChannel.cpp, line 1823
[Child 1815] ###!!! ABORT: Aborting on channel error.: file /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/glue/MessageChannel.cpp, line 1823


GDB output:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff1fabe39 in g_type_check_instance () from /usr/lib/libgobject-2.0.so.0
(gdb) backtrace
#0  0x00007ffff1fabe39 in g_type_check_instance () from /usr/lib/libgobject-2.0.so.0
#1  0x00007ffff1fa0e7e in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#2  0x00007ffff1fa212f in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#3  0x00007ffff2203ece in ?? () from /usr/lib/libgio-2.0.so.0
#4  0x00007ffff1cb2dc7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#5  0x00007ffff1cb3020 in ?? () from /usr/lib/libglib-2.0.so.0
#6  0x00007ffff1cb30cc in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#7  0x00007fffe5faf0ff in nsAppShell::ProcessNextNativeEvent(bool) () from /home/flh/Downloads/firefox/libxul.so
#8  0x00007fffe5fae224 in nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) () from /home/flh/Downloads/firefox/libxul.so
#9  0x00007fffe5efbbe2 in nsThread::ProcessNextEvent(bool, bool*) () from /home/flh/Downloads/firefox/libxul.so
#10 0x00007fffe5f04471 in NS_ProcessNextEvent(nsIThread*, bool) () from /home/flh/Downloads/firefox/libxul.so
#11 0x00007fffe5f1cfd3 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () from /home/flh/Downloads/firefox/libxul.so
#12 0x00007fffe6497813 in MessageLoop::Run() () from /home/flh/Downloads/firefox/libxul.so
#13 0x00007fffe75c5e08 in nsBaseAppShell::Run() () from /home/flh/Downloads/firefox/libxul.so
#14 0x00007fffe7bcefdc in nsAppStartup::Run() () from /home/flh/Downloads/firefox/libxul.so
#15 0x00007fffe7c09ee2 in XREMain::XRE_mainRun() () from /home/flh/Downloads/firefox/libxul.so
#16 0x00007fffe7c0c615 in XREMain::XRE_main(int, char**, nsXREAppData const*) () from /home/flh/Downloads/firefox/libxul.so
#17 0x00007fffe7c0c8a5 in XRE_main () from /home/flh/Downloads/firefox/libxul.so
#18 0x00000000004090d6 in do_main(int, char**, nsIFile*) ()
#19 0x00000000004054ae in main ()

Comment 7

[Milan Bouchet-Valat]

I say "maybe 43", so it might as well be 41. Also I'm on Fedora, not arch, and it uses GTK3 by default (so we serve as guinea pigs for other users :-).

Comment 8

[Edward O]

Victim of this in fedora 23 for a while but I thought it was specific to my configuration... There is no such thing as an "official gtk3 build" to test with,  right? So how can we help?

Comment 9

[Francis Herne]

The official nightly builds (https://nightly.mozilla.org/) have been against gtk3 for a while.

Comment 10

[:Gijs (he/him)]

(In reply to Milan Bouchet-Valat from comment #7)
> I say "maybe 43", so it might as well be 41. Also I'm on Fedora, not arch,
> and it uses GTK3 by default (so we serve as guinea pigs for other users :-).

comment #1 was the only earlier comment that named a distro, hence my question about arch. Sorry for not qualifying it.

It sounds like this is all gtk3-specific.

(In reply to Edward O from comment #8)
> Victim of this in fedora 23 for a while but I thought it was specific to my
> configuration... There is no such thing as an "official gtk3 build" to test
> with,  right? So how can we help?

45 (currently beta) and later are all built with gtk3. As for helping, it would probably help if there were simple steps to reproduce from a clean profile (e.g. "1. go to http://example.com/, 2. click link X to download, 3. in the dialog, pick button <whatever>, 4. expect: dialog opens; actual: crash" - or are we crashing when accepting the dialog? Earlier/later?).

Either way, this is a gtk widget bug. Maybe Karl can tell what's going on from the stack trace.

Comment 11

[Milan Bouchet-Valat]

Any file will do to reproduce the crash, as long as Firefox allows you to choose a different app to open this file type. For example, download the latest nightly:
https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-47.0a1.en-US.linux-i686.tar.bz2

Then click on the applications list, choose Other. The dialog to choose an application opens: close it by hitting Select. Crash!

Comment 12

[Francis Herne]

I've been using http://www.fileformat.info/format/tiff/sample/ when deliberately triggering it - click any of the 'Download' links. Any other file that isn't handled directly by Firefox or a plugin will have the same effect though.

Dialogs screenshot:
http://i.cubeupload.com/Ha6vED.png

When the combobox on the first (left-hand) dialog is left in its initial state, Firefox doesn't crash. You can press 'Ok' (hidden behind other dialog) and the file is opened in the default application.

When selecting 'Other...' in that combobox, the right-hand dialog is shown.

Pressing 'Select' in this dialog always causes Firefox to crash, even when selecting the default application that works from the previous dialog.
Pressing 'Cancel' is fine.

One thing I noticed - when opening the same filetype in future, the default option in the combobox is changed to the application selected immediately before the crash. Not sure if this is normal behaviour, but it works as a really awkward workaround (other option is save-as and then open externally).

Comment 13

[Karl Tomlinson (:karlt)]

I haven't reproduced with the steps in comment 12 and glib-2.44.1 on Gentoo.

Comment 0 had GLib version 0.46.2.
Similarly crash reports [0] only have version 2.46.0 and newer.

Evidence so far suggests a bug in GIO.
Installing debug symbols for the GLib/GIO package my help to identify in a
stack trace.

[0] https://crash-stats.mozilla.com/search/?signature=~libgobject-2.0.so&release_channel=nightly&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

Comment 14

[Martin Stránský [:stransky] (ni? me)]

Downstream report: https://bugzilla.redhat.com/show_bug.cgi?id=1291190#c18

Seems to be caused by gtk3-3.18.x and the gtk_widget_destroy(). We're going to use a workaround on Fedora 23 when the dialog hides and then will be destroyed by parent widget.

Comment 15

[Martin Stránský [:stransky] (ni? me)]

Seems to be 3.18.X only:
F22 (gtk3-3.16.7) - OK
F23 (gtk3-3.18.x) - crashes
Rawhide (gtk3-3.19.7) - OK

Comment 16

[Francis Herne]

On Arch still here.

Firefox crashes when using glib 2.46.2, using each gtk version:
 - 3.16.7
 - 3.17.9
 - 3.18.7

Firefox did _not_ crash when using glib 2.43.4 and gtk 3.16.7.

Gtk 3.18 wasn't compatible with glib 2.43.

Firefox did crash with gtk 3.18 and glib 2.45.8.

Comment 17

[Martin Stránský [:stransky] (ni? me)]

(In reply to Martin Stránský from comment #15)
> Rawhide (gtk3-3.19.7) - OK

I was wrong here - it still crashes (glib2-2.47.5-1.fc24.x86_64). Looks like a kind of race conditions when the dialog is destroyed. We can't reproduce that under 'rr' and it does not crash sometime.

Comment 18

[Francis Herne]

Compiling glib2 with debug symbols didn't seem to help, I got an identical backtrace to the one above (except the addresses).

Comment 19

[Martin Stránský [:stransky] (ni? me)]

The affected component is GAppInfoMonitor() instance managed by gcontextspecificgroup.c. It creates GAppInfoMonitor() component (called from gtk_app_chooser_widget_init()) and the GAppInfoMonitor() instance is released by gtk_widget_destroy() (called from nsApplicationChooser::Done()).

Looks like we need to call g_context_specific_group_remove() somehow, g_context_specific_source_dispatch() is called otherwise (after gtk_widget_destroy()) which causes the crash.

Comment 20

[Martin Stránský [:stransky] (ni? me)]

For debugging just put breakpoint to g_context_specific_source_new().

Comment 23

[Christian Stadelmann]

In Fedora this bug is marked as fixed, but it isn't here. Reasons?

Comment 24

[Martin Stránský [:stransky] (ni? me)]

(In reply to Christian Stadelmann from comment #23)
> In Fedora this bug is marked as fixed, but it isn't here. Reasons?

That was marked bythe Fedora update system when we released a workaround for this. The workaround replaces gtk_widget_destroy() by gtk_widget_hide() and let parent widget destroy the AppChooser dialog.

If Mozilla is interested in such workaround I'll happily post it here. I'm still working on a proper fix for that. Or at least to find out why GIO 2.46 calls the g_context_specific_source_dispatch() after widget destroy.

Comment 25

[Martin Stránský [:stransky] (ni? me)]

I finally managed to figure out what's going on here. GAppInfoMonitor is an internal component of GtkAppChooser which controlls list of active applications.

When gtk_widget_destroy() in called on running instance of GtkAppChooser dialog, GtkAppChooser delete event is dispatched and the GtkAppChooser component is destroyed. The attached GAppInfoMonitor "selection" handler is also dispatched but GAppInfoMonitor events are processed by different thread (gmain_worker thread) so there is a race condition between GtkAppChooser and GAppInfoMonitor handlers. 

The crash happens when GAppInfoMonitor "selection" handler is executed from gmain_worker thread when GtkAppChooser is actually deleted but GAppInfoMonitor still expect it here.

Unfortunately we can't get GAppInfoMonitor from GtkAppChooser and replace the selection handler.

Comment 26

[Martin Stránský [:stransky] (ni? me)]

Attachment: patch

Actually I believe this is the correct fix. To hide the AppChooser dialog and let parent widget to destroy it. 

The GAppMonitor selection event is fired when application is selected from the list so we should not destroy the AppChooser dialog from selection handler.

Comment 27

[Karl Tomlinson (:karlt)]

Comment on attachment 8722938 [details] [diff] [review]
patch

>-  gtk_widget_destroy(chooser);
>+  // Hide the AppChooser dialog and let parent widget to destroy it to avoid
>+  // race conditions between AppChooser internal components
>+  gtk_widget_hide(chooser);

The transient-for parent won't destroy the dialog until the parent is
destroyed.  Many of these dialogs may be leaked until the parent is destroyed. 

Calling gtk_Widget_destroy() from the response handler is appropriate because
this is indicated in the example in the documentation:
https://developer.gnome.org/gtk3/3.18/GtkDialog.html#GtkDialog.description

If absolutely necessary, we can introduce a leak to work around a crash in
system libraries, but I'd like to know which versions of system libraries
introduced and fixed the bug so that we can limit the leaking to systems with
unfixed libraries.

(In reply to Martin Stránský from comment #25)
> The crash happens when GAppInfoMonitor "selection" handler is executed from
> gmain_worker thread when GtkAppChooser is actually deleted but
> GAppInfoMonitor still expect it here.

Can you link to the code that attaches the GtkAppChooser to this
"selection" handler, and paste a stack trace of the crash, please?

Comment 28

[Martin Stránský [:stransky] (ni? me)]

> Calling gtk_Widget_destroy() from the response handler is appropriate because
> this is indicated in the example in the documentation:

You're right, I was confused by the gtk_dialog_run()

> Can you link to the code that attaches the GtkAppChooser to this
> "selection" handler, and paste a stack trace of the crash, please?

The GAppInfoMonitor GObject and GSource (css) for it is created here:

#0  0x00007ffff2dbc2ff in g_context_specific_group_get (group=0x7ffff3157520 <g_app_info_monitor_group>, type=140736460923584, context_offset=24, start_func=0x0) at gcontextspecificgroup.c:196
#1  0x00007ffff2db50d9 in g_app_info_monitor_get () at gappinfo.c:1131
#2  0x00007ffff565aa7b in gtk_app_chooser_widget_init (self=0x7ffff6b6b570 [GtkAppChooserWidget])
    at gtkappchooserwidget.c:1155

When user selects an application in the list g_file_monitor_source_dispatch() is fired and it queues GAppInfoMonitor GSource (css) to immediately dispatch by g_context_specific_group_emit():

g_source_set_ready_time ((GSource *) css, 0);

And this causes the crash at comment 6.

(gdb) bt
#0  0x00007ffff2dbc4c5 in g_context_specific_group_emit (group=0x7ffff3157520 <g_app_info_monitor_group>, signal_id=516)
    at gcontextspecificgroup.c:244
#1  0x00007ffff2db50f3 in g_app_info_monitor_fire () at gappinfo.c:1140
#2  0x00007ffff2e428fb in desktop_file_dir_changed (monitor=0x7fffd40d13e0 [GInotifyFileMonitor], file=0x7fffbef6dfa0, other_file=0x0, event_type=G_FILE_MONITOR_EVENT_CREATED, user_data=0x7fffd4089e00) at gdesktopappinfo.c:243
#3  0x00007fffee793c58 in ffi_call_unix64 () at ../src/x86/unix64.S:76
#4  0x00007fffee7936ba in ffi_call (cif=<optimized out>, fn=<optimized out>, rvalue=<optimized out>, avalue=0x7fffd318b6f0)
    at ../src/x86/ffi64.c:525
#5  0x00007ffff2b3a976 in g_cclosure_marshal_generic_va (closure=0x7fffd40d1440, return_value=0x0, instance=0x7fffd40d13e0, args_list=0x7fffd318bbd0, marshal_data=0x0, n_params=3, param_types=0x7fffd1fbd9e0) at gclosure.c:1604
#6  0x00007ffff2b38d58 in _g_closure_invoke_va (closure=0x7fffd40d1440, return_value=0x0, instance=0x7fffd40d13e0, args=0x7fffd318bbd0, n_params=3, param_types=0x7fffd1fbd9e0) at gclosure.c:867
#7  0x00007ffff2b5569c in g_signal_emit_valist (instance=0x7fffd40d13e0, signal_id=292, detail=0, var_args=0x7fffd318bbd0)
    at gsignal.c:3294
#8  0x00007ffff2b568b7 in g_signal_emit (instance=0x7fffd40d13e0, signal_id=292, detail=0) at gsignal.c:3441
#9  0x00007ffff2de4dd0 in g_file_monitor_emit_event (monitor=0x7fffd40d13e0 [GInotifyFileMonitor], child=0x7fffbef6dfa0, other_file=0x0, event_type=G_FILE_MONITOR_EVENT_CREATED) at gfilemonitor.c:290
#10 0x00007ffff2ed1eb9 in g_file_monitor_source_dispatch (source=0x7fffd1f3bf00, callback=0x0, user_data=0x0)
    at glocalfilemonitor.c:546
#11 0x00007ffff2851f9b in g_main_dispatch (context=0x7fffd423d740) at gmain.c:3154
#12 0x00007ffff2852e6b in g_main_context_dispatch (context=0x7fffd423d740) at gmain.c:3769
#13 0x00007ffff285305e in g_main_context_iterate (context=0x7fffd423d740, block=1, dispatch=1, self=0x7fffd4093470)
    at gmain.c:3840
#14 0x00007ffff2853136 in g_main_context_iteration (context=0x7fffd423d740, may_block=1) at gmain.c:3901
#15 0x00007ffff2854d9f in glib_worker_main (data=0x0) at gmain.c:5672
#16 0x00007ffff2881983 in g_thread_proxy (data=0x7fffd4093470) at gthread.c:780
#17 0x00007ffff7bc169a in start_thread (arg=0x7fffd318c700) at pthread_create.c:333
#18 0x00007ffff6e4508d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

We also call gtk_widget_destroy() from the dialog handler, it deletes GAppInfoMonitor GObject in main thread by g_context_specific_group_remove() before the above event is processed.

#0  0x00007ffff2dbc37e in g_context_specific_group_remove (group=0x7ffff3157520 <g_app_info_monitor_group>, context=0x7fffd8713060, instance=0x7fffc2e56340, stop_func=0x0) at gcontextspecificgroup.c:217
#1  0x00007ffff2db4ffc in g_app_info_monitor_finalize (object=0x7fffc2e56340 [GAppInfoMonitor]) at gappinfo.c:1084
#2  0x00007ffff2b456f3 in g_object_unref (_object=0x7fffc2e56340) at gobject.c:3183
#3  0x00007ffff565a251 in gtk_app_chooser_widget_finalize (object=0x7ffff6b6b570 [GtkAppChooserWidget])
    at gtkappchooserwidget.c:923
#4  0x00007ffff2b456f3 in g_object_unref (_object=0x7ffff6b6b570) at gobject.c:3183
#5  0x00007ffff2b40732 in g_object_run_dispose (object=0x7ffff6b6b570 [GtkAppChooserWidget]) at gobject.c:1084
#6  0x00007ffff59eb0b4 in gtk_widget_destroy (widget=0x7ffff6b6b570 [GtkAppChooserWidget]) at gtkwidget.c:4712
#7  0x00007ffff567aaf0 in gtk_box_forall (container=0x7fffc2cfd1e0 [GtkBox], include_internals=0, callback=0x7ffff59eaffd <gtk_widget_destroy>, callback_data=0x0) at gtkbox.c:2657
#8  0x00007ffff56e3809 in gtk_container_foreach (container=0x7fffc2cfd1e0 [GtkBox], callback=0x7ffff59eaffd <gtk_widget_destroy>, callback_data=0x0) at gtkcontainer.c:2444
#9  0x00007ffff56e1ac0 in gtk_container_destroy (widget=0x7fffc2cfd1e0 [GtkBox]) at gtkcontainer.c:1699
#10 0x00007ffff2b3bc97 in g_cclosure_marshal_VOID__VOID (closure=0x7fffd8715320, return_value=0x0, n_param_values=1, param_values=0x7fffffff85a0, invocation_hint=0x7fffffff8550, marshal_data=0x7ffff56e19fd <gtk_container_destroy>) at gmarshal.c:875
#11 0x00007ffff2b39154 in g_type_class_meta_marshal (closure=0x7fffd8715320, return_value=0x0, n_param_values=1, param_values=0x7fffffff85a0, invocation_hint=0x7fffffff8550, marshal_data=0x98) at gclosure.c:997
#15 0x00007ffff2b568b7 in <emit signal ??? on instance 0x7fffc2cfd1e0 [GtkBox]> (instance=0x7fffc2cfd1e0, signal_id=28, detail=0) at gsignal.c:3441
    #12 0x00007ffff2b38a70 in g_closure_invoke (closure=0x7fffd8715320, return_value=0x0, n_param_values=1, param_values=0x7fffffff85a0, invocation_hint=0x7fffffff8550) at gclosure.c:804
    #13 0x00007ffff2b57590 in signal_emit_unlocked_R (node=0x7ffff6bd4f40, detail=0, instance=0x7fffc2cfd1e0, emission_return=0x0, instance_and_params=0x7fffffff85a0) at gsignal.c:3745
    #14 0x00007ffff2b56346 in g_signal_emit_valist (instance=0x7fffc2cfd1e0, signal_id=28, detail=0, var_args=0x7fffffff8810)
    at gsignal.c:3385
#16 0x00007ffff59fa00b in gtk_widget_dispose (object=0x7fffc2cfd1e0 [GtkBox]) at gtkwidget.c:12033
#17 0x00007ffff5674e6f in gtk_box_dispose (object=0x7fffc2cfd1e0 [GtkBox]) at gtkbox.c:244
#18 0x00007ffff2b4071b in g_object_run_dispose (object=0x7fffc2cfd1e0 [GtkBox]) at gobject.c:1082
#19 0x00007ffff59eb0b4 in gtk_widget_destroy (widget=0x7fffc2cfd1e0 [GtkBox]) at gtkwidget.c:4712
#20 0x00007ffff567aaf0 in gtk_box_forall (container=0x7fffc2cfca00 [GtkBox], include_internals=0, callback=0x7ffff59eaffd <gtk_widget_destroy>, callback_data=0x0) at gtkbox.c:2657
#21 0x00007ffff56e3809 in gtk_container_foreach (container=0x7fffc2cfca00 [GtkBox], callback=0x7ffff59eaffd <gtk_widget_destroy>, callback_data=0x0) at gtkcontainer.c:2444
#22 0x00007ffff56e1ac0 in gtk_container_destroy (widget=0x7fffc2cfca00 [GtkBox]) at gtkcontainer.c:1699
#23 0x00007ffff2b3bc97 in g_cclosure_marshal_VOID__VOID (closure=0x7fffd8715320, return_value=0x0, n_param_values=1, param_values=0x7fffffff8d70, invocation_hint=0x7fffffff8d20, marshal_data=0x7ffff56e19fd <gtk_container_destroy>) at gmarshal.c:875
#24 0x00007ffff2b39154 in g_type_class_meta_marshal (closure=0x7fffd8715320, return_value=0x0, n_param_values=1, param_values=0x7fffffff8d70, invocation_hint=0x7fffffff8d20, marshal_data=0x98) at gclosure.c:997
#28 0x00007ffff2b568b7 in <emit signal ??? on instance 0x7fffc2cfca00 [GtkBox]> (instance=0x7fffc2cfca00, signal_id=28, detail=0) at gsignal.c:3441
    #25 0x00007ffff2b38a70 in g_closure_invoke (closure=0x7fffd8715320, return_value=0x0, n_param_values=1, param_values=0x7fffffff8d70, invocation_hint=0x7fffffff8d20) at gclosure.c:804
    #26 0x00007ffff2b57590 in signal_emit_unlocked_R (node=0x7ffff6bd4f40, detail=0, instance=0x7fffc2cfca00, emission_return=0x0, instance_and_params=0x7fffffff8d70) at gsignal.c:3745
    #27 0x00007ffff2b56346 in g_signal_emit_valist (instance=0x7fffc2cfca00, signal_id=28, detail=0, var_args=0x7fffffff8fe0)
    at gsignal.c:3385
#29 0x00007ffff59fa00b in gtk_widget_dispose (object=0x7fffc2cfca00 [GtkBox]) at gtkwidget.c:12033
#30 0x00007ffff5674e6f in gtk_box_dispose (object=0x7fffc2cfca00 [GtkBox]) at gtkbox.c:244
#31 0x00007ffff2b4071b in g_object_run_dispose (object=0x7fffc2cfca00 [GtkBox]) at gobject.c:1082
#32 0x00007ffff59eb0b4 in gtk_widget_destroy (widget=0x7fffc2cfca00 [GtkBox]) at gtkwidget.c:4712
#33 0x00007ffff5a18f96 in gtk_window_forall (container=0x7fffbe438ee0 [GtkAppChooserDialog], include_internals=0, callback=0x7ffff59eaffd <gtk_widget_destroy>, callback_data=0x0) at gtkwindow.c:8277
#34 0x00007ffff56e3809 in gtk_container_foreach (container=0x7fffbe438ee0 [GtkAppChooserDialog], callback=0x7ffff59eaffd <gtk_widget_destroy>, callback_data=0x0) at gtkcontainer.c:2444
#35 0x00007ffff56e1ac0 in gtk_container_destroy (widget=0x7fffbe438ee0 [GtkAppChooserDialog]) at gtkcontainer.c:1699
#36 0x00007ffff5a13228 in gtk_window_destroy (widget=0x7fffbe438ee0 [GtkAppChooserDialog]) at gtkwindow.c:5873
#37 0x00007ffff2b3bc97 in g_cclosure_marshal_VOID__VOID (closure=0x7fffd8715320, return_value=0x0, n_param_values=1, param_values=0x7fffffff9580, invocation_hint=0x7fffffff9530, marshal_data=0x7ffff5a13100 <gtk_window_destroy>) at gmarshal.c:875
#38 0x00007ffff2b39154 in g_type_class_meta_marshal (closure=0x7fffd8715320, return_value=0x0, n_param_values=1, param_values=0x7fffffff9580, invocation_hint=0x7fffffff9530, marshal_data=0x98) at gclosure.c:997
#42 0x00007ffff2b568b7 in <emit signal ??? on instance 0x7fffbe438ee0 [GtkAppChooserDialog]> (instance=0x7fffbe438ee0, signal_id=28, detail=0) at gsignal.c:3441
    #39 0x00007ffff2b38a70 in g_closure_invoke (closure=0x7fffd8715320, return_value=0x0, n_param_values=1, param_values=0x7fffffff9580, invocation_hint=0x7fffffff9530) at gclosure.c:804
    #40 0x00007ffff2b57590 in signal_emit_unlocked_R (node=0x7ffff6bd4f40, detail=0, instance=0x7fffbe438ee0, emission_return=0x0, instance_and_params=0x7fffffff9580) at gsignal.c:3745
    #41 0x00007ffff2b56346 in g_signal_emit_valist (instance=0x7fffbe438ee0, signal_id=28, detail=0, var_args=0x7fffffff97f0)
    at gsignal.c:3385
#43 0x00007ffff59fa00b in gtk_widget_dispose (object=0x7fffbe438ee0 [GtkAppChooserDialog]) at gtkwidget.c:12033
#44 0x00007ffff5a0e01c in gtk_window_dispose (object=0x7fffbe438ee0 [GtkAppChooserDialog]) at gtkwindow.c:3117
#45 0x00007ffff565ebef in gtk_app_chooser_dialog_dispose (object=0x7fffbe438ee0 [GtkAppChooserDialog])
    at gtkappchooserdialog.c:573
#46 0x00007ffff2b4071b in g_object_run_dispose (object=0x7fffbe438ee0 [GtkAppChooserDialog]) at gobject.c:1082
#47 0x00007ffff59eb0b4 in gtk_widget_destroy (widget=0x7fffbe438ee0 [GtkAppChooserDialog]) at gtkwidget.c:4712
#48 0x00007fffe4c90e71 in nsApplicationChooser::Done(_GtkWidget*, int) (this=0x7fffc26a1340, chooser=0x7fffbe438ee0 [GtkAppChooserDialog], response=-5) at /home/komat/tmp676-trunk-gtk3/src-light/widget/gtk/nsApplicationChooser.cpp:117

Comment 29

[Karl Tomlinson (:karlt)]

Looking at the source, without reproducing to confirm:

g_context_specific_group_get() attaches a source pointing at a new
G_TYPE_APP_INFO_MONITOR to the context:
https://git.gnome.org/browse/glib/tree/gio/gcontextspecificgroup.c?h=2.46.2#n191

g_context_specific_source_dispatch() always returns G_SOURCE_CONTINUE:
https://git.gnome.org/browse/glib/tree/gio/gcontextspecificgroup.c?h=2.46.2#n56

g_context_specific_group_remove() is called when the G_TYPE_APP_INFO_MONITOR
is finalized, but does not remove the source from the context nor detach the
G_TYPE_APP_INFO_MONITOR instance from the source.  It merely unrefs the
source:

https://git.gnome.org/browse/glib/tree/gio/gcontextspecificgroup.c?h=2.46.2#n225

I don't see anything to detach the source from the context.
Seems we are missing a g_source_destroy() in remove.

g_source_attach increments the ref count so unref is not enough to finalize:
https://git.gnome.org/browse/glib/tree/glib/gmain.c?h=2.46.2#n1111

This code was in 2.44.1 so I don't know why it is not reproducing there.
Perhaps something in this changeset triggered:

https://git.gnome.org/browse/glib/commit/?id=2737ab3201163631be152801a859b3874a667f10

Comment 30

[Martin Stránský [:stransky] (ni? me)]

Matthias told me it's a bug in GIO so I filled it at b.g.o (https://bugzilla.gnome.org/show_bug.cgi?id=762994) with a minimal testcase.

Comment 32

[Francis Herne]

This is still broken with glib2 2.48.0 and Firefox 45.0.1

Comment 34

[Exchie]

I'm sorry, this bug was opened at january, but it is april presently. Why this bug is still not fixed?

Comment 35

[Exchie]

It's really annoying.

Comment 36

[Francis Herne]

Well, GTK3 isn't enabled by default in the official release, only in betas and by certain distros.

It really is quite annoying though.

Comment 37

[Exchie]

May be there is an workaround to fix it on fly? Like to turn some features off or so on?

Comment 38

[Francis Herne]

Don't build againt GTK3...

Comment 39

[Exchie]

Hmmm... I'm not a programmer. And I use only pre-built one from the official repo.

Comment 40

[Karl Tomlinson (:karlt)]

Fixed in https://git.gnome.org/browse/glib/commit/?id=62f320e
which is on https://git.gnome.org/browse/glib/log/?h=glib-2-48
for 2.48.1.

I guess the application chooser could be disabled if broken, but it would be better to fix the GIO library installed.

Comment 41

[B. Dahse]

Firefox 46.0 on Ubuntu 15.10 is still affected by this.
Exactly as the bug description, any attempt to open a file with non-default application causes a segmentation fault in g_type_check_instance () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.
I have run a mozregression and found the regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1ee54e043b9b05d69e6a9f981aa6c4ef0dd65be3&tochange=939320b957c588ad809e9b4a64b7f232dd4d9b72

Comment 42

[:Gijs (he/him)]

Should we take a modified version of Martin's patch that only applies the leaky workaround on buggy glib versions?

Comment 43

[Karl Tomlinson (:karlt)]

Delaying destruction until the owning window is destroyed would still permit destruction when the main window is closed, and so I guess would not always avoid the crash.

Probably better to disable the application chooser for buggy versions.

Comment 44

[Martin Stránský [:stransky] (ni? me)]

(In reply to Karl Tomlinson (ni?:karlt) from comment #43)
> Delaying destruction until the owning window is destroyed would still permit
> destruction when the main window is closed, and so I guess would not always
> avoid the crash.

Confirmed. I saw the crash once with this patch.

Comment 45

[:Gijs (he/him)]

(In reply to Karl Tomlinson (ni?:karlt) from comment #43)
> Probably better to disable the application chooser for buggy versions.

OK, then would it make sense to reopen this and for someone to write a patch for that? It seems like common distros don't ship fixed versions of GIO yet and so this will happen to "a lot" of people, which seems unfortunate.

Comment 46

[Karl Tomlinson (:karlt)]

I don't feel Mozilla is responsible for this bug.  If many people are affected, then they'll report the bug to their distributions and the libraries will be fixed.  It is a one line patch.  We don't need to fix it twice.

I'm happy to review a patch that disables in the buggy versions, but there is no point having the bug open until there is a patch.

Comment 48

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'libgobject-2.0.so.0.4600.2@0x34e39':
 - nightly(version 50):2 crashes from 2016-06-06.
 - aurora (version 49):3 crashes from 2016-06-07.
 - beta   (version 48):12 crashes from 2016-06-06.
 - release(version 47):218 crashes from 2016-05-31.
 - esr    (version 45):0 crashes from 2016-04-07.

Crash volume on the last weeks:
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       0       0       1       0       0       0       1
 - aurora        0       0       0       2       0       0       1
 - beta          0       0       1       2       4       0       1
 - release      18      38      40      31      29      30      26
 - esr           0       0       0       0       0       0       0

Affected platform: Linux

Comment 49

[BugBot [:suhaib / :marco/ :calixte]]

Crash volume for signature 'libgobject-2.0.so.0.4800.0@0x34d99':
 - nightly (version 51): 1 crash from 2016-08-01.
 - aurora  (version 50): 0 crashes from 2016-08-01.
 - beta    (version 49): 0 crashes from 2016-08-02.
 - release (version 48): 31 crashes from 2016-07-25.
 - esr     (version 45): 0 crashes from 2016-05-02.

Crash volume on the last weeks (Week N is from 08-22 to 08-28):
            W. N-1  W. N-2  W. N-3
 - nightly       0       0       1
 - aurora        0       0       0
 - beta          0       0       0
 - release      13       8       3
 - esr           0       0       0

Affected platform: Linux

Crash rank on the last 7 days:
           Browser     Content   Plugin
 - nightly
 - aurora
 - beta
 - release #1445
 - esr