Bug 441084

Does "currently" mean Rawhide? I don't see anything here on F-8 even with gdb.

Yes i meant rawhide (see BZ "Version" field :-) ).

I see. Then I guess it's due to your libsigc++20 2.2 update, right? I brief look
on the code showed that sigc::slot was used, this needs to be replaced I guess.

Possibly, but honestly I think very unlikely because the libsigc++ update was
ABI compatible, they just turned off a bunch of typedefs to support the old API.
Also, sigc::slot is still valid, but only in its templatized form
(sigc::slot<return type, arg1 type, arg2 type, ...>). Regexxer use of libsigc++
looks good to me.

Here's the top30 of the stack track :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7f9b940 (LWP 8139)]
__pthread_mutex_destroy (mutex=0x0) at pthread_mutex_destroy.c:28
28	  if ((mutex->__data.__kind & PTHREAD_MUTEX_ROBUST_NORMAL_NP) == 0
Missing separate debuginfos, use: debuginfo-install bug-buddy.i386 dbus.i386
elfutils.i386 fontconfig.i386 freetype.i386 gamin.i386 gcc.i386
gtk-nodoka-engine.i386 libXau.i386 libXcomposite.i386 libXcursor.i386
libXdmcp.i386 libXext.i386 libXfixes.i386 libXi.i386 libXinerama.i386
libXrandr.i386 libXrender.i386 libbeagle.i386 libcap.i386 libpng.i386
libselinux.i386 libxcb.i386 pixman.i386 zlib.i386
(gdb) bt
#0  __pthread_mutex_destroy (mutex=0x0) at pthread_mutex_destroy.c:28
#1  0x010110e6 in pthread_mutex_destroy (mutex=0x0) at forward.c:176
#2  0x05e9113e in g_mutex_free_posix_impl (mutex=0x0) at gthread-posix.c:171
#3  0x0474d3a7 in g_mount_tracker_finalize (object=0x92a92b0) at gmounttracker.c:239
#4  0x00cb7283 in IA__g_object_unref (_object=0x92a92b0) at gobject.c:1793
#5  0x04739ee7 in g_daemon_volume_monitor_finalize (object=0x92a9298) at
gdaemonvolumemonitor.c:249
#6  0x00cb7283 in IA__g_object_unref (_object=0x92a9298) at gobject.c:1793
#7  0x085258a8 in g_union_volume_monitor_finalize (object=0x92a9238) at
gunionvolumemonitor.c:73
#8  0x00cb7283 in IA__g_object_unref (_object=0x92a9238) at gobject.c:1793
#9  0x081c3ec4 in gtk_file_system_gio_dispose (object=0x92a9220) at
gtkfilesystemgio.c:479
#10 0x00cb71e8 in IA__g_object_unref (_object=0x92a9220) at gobject.c:1765
#11 0x0061bde9 in gtk_file_chooser_button_destroy (object=0x92a5518) at
gtkfilechooserbutton.c:972
#12 0x002bf1d0 in Gtk::Container_Class::destroy_callback (self=0x92a5518) at
container.cc:257
#13 0x00cc2834 in IA__g_cclosure_marshal_VOID__VOID (closure=0x9271848,
return_value=0x0, n_param_values=1, 
    param_values=0xbfeb6308, invocation_hint=0xbfeb623c, marshal_data=0x2bf1a0)
at gmarshal.c:77
#14 0x00cb38a9 in g_type_class_meta_marshal (closure=0x9271848,
return_value=0x0, n_param_values=1, 
    param_values=0xbfeb6308, invocation_hint=0xbfeb623c, marshal_data=0x4c) at
gclosure.c:567
#15 0x00cb5058 in IA__g_closure_invoke (closure=0x9271848, return_value=0x0,
n_param_values=1, 
    param_values=0xbfeb6308, invocation_hint=0xbfeb623c) at gclosure.c:490
#16 0x00cc9b4a in signal_emit_unlocked_R (node=0x929dd70, detail=0,
instance=0x92a5518, emission_return=0x0, 
    instance_and_params=0xbfeb6308) at gsignal.c:2556
#17 0x00ccac0e in IA__g_signal_emit_valist (instance=0x92a5518, signal_id=7,
detail=0, 
    var_args=0xbfeb651c "\030U*\t") at gsignal.c:2199
#18 0x00ccb076 in IA__g_signal_emit (instance=0x92a5518, signal_id=7, detail=0)
at gsignal.c:2243
#19 0x006d1eeb in gtk_object_dispose (gobject=0x92a5518) at gtkobject.c:418
#20 0x0081c7d5 in gtk_widget_dispose (object=0x92a5518) at gtkwidget.c:7854
#21 0x00372b8c in Gtk::Widget_Class::dispose_vfunc_callback (self=0x92a5518) at
widget.cc:548
#22 0x00cb772f in IA__g_object_run_dispose (object=0x92a5518) at gobject.c:573
#23 0x006d1e92 in IA__gtk_object_destroy (object=0x92a5518) at gtkobject.c:403
#24 0x0081345c in IA__gtk_widget_destroy (widget=0x92a5518) at gtkwidget.c:2889
#25 0x0074d154 in gtk_table_forall (container=0x9295460, include_internals=0, 
    callback=0x8133cd <IA__gtk_widget_destroy>, callback_data=0x0) at gtktable.c:931
#26 0x002bef6e in Gtk::Container::forall_vfunc (this=0xb5b03758,
include_internals=0, 
    callback=0x8133cd <IA__gtk_widget_destroy>, callback_data=0x0) at
container.cc:1019
#27 0x002c0651 in Gtk::Container_Class::forall_vfunc_callback (self=0x9295460,
include_internals=0, 
    callback=0x8133cd <IA__gtk_widget_destroy>, callback_data=0x0) at
container.cc:476
#28 0x005e9bcf in IA__gtk_container_foreach (container=0x9295460,
callback=0x8133cd <IA__gtk_widget_destroy>, 
    callback_data=0x0) at gtkcontainer.c:1480
#29 0x005e8a11 in gtk_container_destroy (object=0x9295460) at gtkcontainer.c:1020
#30 0x002bf1d0 in Gtk::Container_Class::destroy_callback (self=0x9295460) at
container.cc:257

This indeed seem so to be a gvfs bug, in the mount_tracker object finalize
method. It should protect the deallocation of the thread lock. Patch attached
(which fixes the regexer code dump).

This probably should get squeezed in before the F-9 release, if possible.

Created attachment 302270 [details]
Fixes mount tracker finalize

Thanks, I've put the fix into gvfs-0.2.3-3.fc9