I'm pretty sure this only broke for me in the past few days, likely by a glib or gtk update that Ubuntu shipped. (I can reproduce it in Firefox Nightly builds going back months, so it's not a recent Firefox regression or I would have hit it by now.)

The two most recent changelog entries for this package (libglib2.0-0) are:
=============
glib2.0 (2.46.0-2) unstable; urgency=medium

  * debian/patches/0001-Revert-list-store-Fix-a-parameter-check.patch:
    Cherry-pick from upstream to fix GSequence (this at least makes
    GStreamer's testsuite fail).

 -- Iain Lane <laney@debian.org>  Mon, 28 Sep 2015 13:07:06 +0100

glib2.0 (2.46.0-1) unstable; urgency=medium

  [ Iain Lane ]
  * New upstream stable release 2.46.0
    + Disable runtime-deprecation warnings
    + Fix marshalling of flags on bigendian 64bit architectures

  [ Simon McVittie ]
  * Change section of libglib2.0-refdbg from debug to devel, so that it
    isn't kicked out into a separate mirror network when we get
    automatic -dbgsym packages (Closes: #796836)

 -- Iain Lane <laney@debian.org>  Wed, 23 Sep 2015 11:33:01 +0100
=============

The version before that in the changelog is 2.45.8-1 (note 45 instead of 46).

So this seems likely to be either a regression in 2.46, or an issue with the Revert-list-store-Fix-a-parameter-check patch (which is for Bug 755496)

(That changelog quoted in comment 2 is
http://changelogs.ubuntu.com/changelogs/pool/main/g/glib2.0/glib2.0_2.46.0-2/changelog
BTW.)

I would suggest to debug this in the Ubuntu bugtracker - I can't reproduce this with glib 2.46 and gtk 3.18.

Thanks for the reply. I'm going to investigate a bit more, and then I'll probably file this in Ubuntu's bug tracker as you suggest.

Two more bits of data: I can still reproduce this after downgrading to 
  libglib2.0-0_2.44.1-1ubuntu1_amd64.deb
...from...
  https://launchpad.net/ubuntu/vivid/amd64/libglib2.0-0/2.44.1-1ubuntu1

So, this doesn't seem to be a regression in my libglib2 package as I'd thought it was.

Also: one time that I triggered this, I got this error output on my terminal:
{
(firefox:3232): GLib-GObject-CRITICAL **: g_object_new_valist: invalid object type 'GVfsDBusMount' for value type 'GDBusConnection'
}
...and from looking at package changelogs in Synaptic, I see that my gvfs packages and associated packages received an update on 10/5 (this Monday) which is right around when this bug started happening to me. So, that's where I'm currently pointing my suspicion...

(I wanted to point suspicion at dbus/libdbus flavored packages, but those all have a "last updated" date of around a month ago.)

Yup, if I downgrade my "gvfs" package (and its various "gvfs-*" packages) back 2 previous versions (1.24.1-1ubuntu4), then this bug goes away.  That version seems to be "good".

So this seems to be a bug in Ubuntu's current gvfs package, which is version 1.24.2-0ubuntu2.

--> Reclassifying to Product=gvfs

Version 1.24.2-0ubuntu1 is good as well. (no crash, after repeated opening of a file-picker dialog on Firefox Nightly)

So 1.24.2-0ubuntu2 is the first bad version.

The changelog for this version is:
gvfs (1.24.2-0ubuntu2) wily; urgency=medium

=====
  * debian/patches/git_construct_sync.patch:
    - back fix for nautilus file trash issues

 -- Sebastien Bacher <seb128@ubuntu.com>  Mon, 05 Oct 2015 16:30:17 +0200
=====

That patch (git_construct_sync.patch) is from bug 749317.  So at first glance, this seems to be a regression from that bug.

Alex, can you reproduce this bug with up-to-date gvfs (including your patch from bug 749317)?

(Note that Firefox Nightly -- needed to reproduce the crash -- can be downloaded from https://nightly.mozilla.org/ . Also, sometimes I need to trigger the file-open several times before the crash happens, but it's never taken more than ~4 attempts.)

Created attachment 312839 [details]
backtrace of crash

Here's the backtrace of the crash (captured in a local Firefox trunk debug build), going up to where Firefox requests a file-picker dialog.

Particularly relevant is stack-level #2 through #5:
===

+ Trace 235549

I'm pretty sure this is code that was modified in bug 749317.  At least, its patch[1]:
 * Adds a call to _g_dbus_connection_get_sync .
 * Mentions g_daemon_file_monitor_file in the commit message.
 * Mentions g_file_monitor_file in the commit message.

[1]https://git.gnome.org/browse/gvfs/commit/?id=7373acf9b15f40f1c01bd2a325b380ba9bc17d19

note that you can trigger warnings by opening/closing/reopen a fileselector in gedit

You are right, this is reproducible with gvfs-1.26.1-1.fc23:

==1279== Invalid read of size 8
==1279==    at 0xBCB6C5E: g_dbus_connection_is_closed (in /usr/lib64/libgio-2.0.so.0.4600.0)
==1279==    by 0x1B4DAC8A: _g_dbus_connection_get_sync (gvfsdaemondbus.c:538)
==1279==    by 0x1B4D1402: create_proxy_for_file2.constprop.3 (gdaemonfile.c:472)
==1279==    by 0x1B4D3197: create_proxy_for_file (gdaemonfile.c:519)
==1279==    by 0x1B4D3197: g_daemon_file_monitor_file (gdaemonfile.c:3148)
==1279==    by 0xBC3403A: g_file_monitor_file (in /usr/lib64/libgio-2.0.so.0.4600.0)
==1279==    by 0xA05EB45: ??? (in /usr/lib64/libgtk-3.so.0.1800.1)
==1279==    by 0xBF99BFA: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.4600.0)
==1279==    by 0xBF7BB8A: ??? (in /usr/lib64/libgobject-2.0.so.0.4600.0)
==1279==    by 0xBF7D470: g_object_newv (in /usr/lib64/libgobject-2.0.so.0.4600.0)
==1279==    by 0xBF7DDA3: g_object_new (in /usr/lib64/libgobject-2.0.so.0.4600.0)
==1279==    by 0xA05EE28: ??? (in /usr/lib64/libgtk-3.so.0.1800.1)
==1279==    by 0x9FA9379: ??? (in /usr/lib64/libgtk-3.so.0.1800.1)
==1279==  Address 0x24791080 is 0 bytes inside a block of size 248 free'd
==1279==    at 0x4C29D6A: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1279==    by 0xC2085ED: g_free (in /usr/lib64/libglib-2.0.so.0.4600.0)
==1279==    by 0xC21FDCC: g_slice_free1 (in /usr/lib64/libglib-2.0.so.0.4600.0)
==1279==    by 0xBF99EA9: g_type_free_instance (in /usr/lib64/libgobject-2.0.so.0.4600.0)
==1279==    by 0x1B4DA14F: g_daemon_file_monitor_finalize (gdaemonfilemonitor.c:71)
==1279==    by 0xBF7B5BE: g_object_unref (in /usr/lib64/libgobject-2.0.so.0.4600.0)
==1279==    by 0xA05ECD3: ??? (in /usr/lib64/libgtk-3.so.0.1800.1)
==1279==    by 0xBF7B53B: g_object_unref (in /usr/lib64/libgobject-2.0.so.0.4600.0)
==1279==    by 0x9FA6B89: ??? (in /usr/lib64/libgtk-3.so.0.1800.1)
==1279==    by 0xBF7CFB8: g_object_run_dispose (in /usr/lib64/libgobject-2.0.so.0.4600.0)
==1279==    by 0x9F9BD21: ??? (in /usr/lib64/libgtk-3.so.0.1800.1)
==1279==    by 0x9EA7F2F: ??? (in /usr/lib64/libgtk-3.so.0.1800.1)
==1279==  Block was alloc'd at
==1279==    at 0x4C28C50: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1279==    by 0xC2084D8: g_malloc (in /usr/lib64/libglib-2.0.so.0.4600.0)
==1279==    by 0xC21F652: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.4600.0)
==1279==    by 0xC21FCED: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.4600.0)
==1279==    by 0xBF99B73: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.4600.0)
==1279==    by 0xBF7BB8A: ??? (in /usr/lib64/libgobject-2.0.so.0.4600.0)
==1279==    by 0xBF7DA24: g_object_new_valist (in /usr/lib64/libgobject-2.0.so.0.4600.0)
==1279==    by 0xBC440FD: g_initable_new_valist (in /usr/lib64/libgio-2.0.so.0.4600.0)
==1279==    by 0xBC441C5: g_initable_new (in /usr/lib64/libgio-2.0.so.0.4600.0)
==1279==    by 0xBCBA2F3: g_dbus_connection_new_for_address_sync (in /usr/lib64/libgio-2.0.so.0.4600.0)
==1279==    by 0x1B4DADB2: _g_dbus_connection_get_sync (gvfsdaemondbus.c:589)
==1279==    by 0x1B4D1402: create_proxy_for_file2.constprop.3 (gdaemonfile.c:472)

Created attachment 313171 [details] [review]
file monitor: Fix invalid read

Commit 7373acf changed file monitor construction to be really synchronous. Unfortunately there is missing g_object_ref for d-bus connection and the connection is unrefed after use. Subsequent read of the unrefed connection cause crash with following critical:

(firefox:29844): GLib-GIO-CRITICAL **: g_dbus_connection_is_closed: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

Do not store the connection, because it isn't neccesary with the synchronous construction.

We should make new stable release because of that probably...

Review of attachment 313171 [details] [review]:

Looks like we're just intentionally leaking the connection?  Is there no object we return that can hold the reference?

*** Bug 756529 has been marked as a duplicate of this bug. ***

(In reply to Colin Walters from comment #14)
> Review of attachment 313171 [details] [review] [review]:
> 
> Looks like we're just intentionally leaking the connection?  Is there no
> object we return that can hold the reference?

_g_dbus_connection_get_sync implements cache for the connections and holds the references for them, so it should be correct, shouldn't it?

The thread-local cache that owns the connection is destroyed when the thread exits (G_PRIVATE_INIT -> pthread_key_create) and the connection is unreffed.

Jan: Sure, but the proxy will keep the connection object alive. I don't see what the problem is?

Clearly the problem is *not* that we should unref the return value from _g_dbus_connection_get_sync, that is what created this crash in the first place.

Anyway, lgtm.

Comment on attachment 313171 [details] [review]
file monitor: Fix invalid read

commit 44d48ebfc3f322dc73d6a0b7b2bf92bdb3e905ee

GVfs 1.26.1.1 has been released including this fix...