After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 753378 - Crashes in the GIO kqueue backend
Crashes in the GIO kqueue backend
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
2.44.x
Other FreeBSD
: Normal major
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2015-08-08 09:29 UTC by walter s.
Modified: 2015-12-23 14:42 UTC
See Also:
GNOME target: 3.18
GNOME version: ---


Attachments
gio: drop obsoleted lock causing deadlocks on FreeBSD (1.97 KB, patch)
2015-12-22 08:35 UTC, Andreas Henriksson
committed Details | Review

Description walter s. 2015-08-08 09:29:41 UTC
firefox, thunderbird, leafpad, libre-office-writer crashes if I try to save. Pcmanfm, nautilus, thunar don't start anymore.

It is diskussed here (someone found a temporary workaround)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202128
Comment 1 Emmanuele Bassi (:ebassi) 2015-08-08 09:49:53 UTC
(re-titling for clarity)
Comment 2 walter s. 2015-08-09 07:23:40 UTC
I don't mentioned it happens after update of following package to:
glib-2.44.1 
cairo-1.14.2,2 
gobject-introspection-1.44.0 
atk-2.16.0
gdk-pixbuf2-2.31.5 
adwaita-icon-theme-3.16.2.1 
libsoup-gnome-2.50.0 
gtk3-3.16.6 
at-spi2-atk-2.16.0 
at-spi2-core-2.16.0 
gdk-pixbuf2-2.31.5
Comment 3 Matthias Clasen 2015-08-18 12:01:55 UTC
It would be useful to have a stacktrace here
Comment 4 walter s. 2015-08-18 12:46:32 UTC
I never worked much with debugger. You have told me how to do this.
Comment 5 Ting-Wei Lan 2015-08-18 13:37:15 UTC
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces/DistroSpecificInstructions#FreeBSD

You can add WITH_DEBUG=yes to /etc/make.conf, rebuild glib from ports, and re-run the program in gdb. Type 'r' in gdb to start the program and type 'bt' to get the stacktrace after it crashes.

I cannot reproduce the problem on my machine, so I cannot provide a backtrace for you.
Comment 6 walter s. 2015-08-18 13:47:05 UTC
Thanks, this commands I found but I got only with leafpad and pcmanfm
(gdb) bt
  • #0 _kevent
    from /lib/libc.so.7
  • #1 pthread_suspend_all_np
    from /lib/libthr.so.3
  • #2 _kqueue_thread_func
    at kqueue-thread.c line 220
  • #3 pthread_create
    from /lib/libthr.so.3
  • #4 ??

Comment 7 Matthias Clasen 2015-08-19 20:03:56 UTC
unfortunately, that is not enough of a stacktrace to say much. Can you try

t a a bt

instead of bt

when you are in gdb ? That will produce a stacktrace with all threads
Comment 8 walter s. 2015-08-19 20:31:39 UTC
Here it is (with leafpad)
no debugging symbols found)...[New LWP 100461]
[New Thread 808806400 (LWP 100461/leafpad)]
^C[New Thread 808a1cc00 (LWP 101228/leafpad)]

Program received signal SIGINT, Interrupt.
[Switching to Thread 808a1cc00 (LWP 101228/leafpad)]
0x000000080359ee6a in _kevent () from /lib/libc.so.7
(gdb) t a a bt
[New Thread 808a64c00 (LWP 101232/leafpad)]

Thread 2 (Thread 808806400 (LWP 100461/leafpad))

  • #0 pthread_cleanup_pop
    from /lib/libthr.so.3
  • #1 _pthread_cond_wait
    from /lib/libthr.so.3
  • #2 g_cond_wait
    from /usr/local/lib/libglib-2.0.so.0
  • #3 g_charset_converter_get_num_fallbacks
    from /usr/local/lib/libgio-2.0.so.0
  • #4 g_charset_converter_get_num_fallbacks
    from /usr/local/lib/libgio-2.0.so.0
  • #5 g_unix_socket_address_abstract_names_supported
    from /usr/local/lib/libgio-2.0.so.0
  • #6 g_type_create_instance
    from /usr/local/lib/libgobject-2.0.so.0
  • #7 g_object_new_valist
    from /usr/local/lib/libgobject-2.0.so.0
  • #8 g_object_newv
    from /usr/local/lib/libgobject-2.0.so.0
  • #9 g_object_new
    from /usr/local/lib/libgobject-2.0.so.0
  • #10 g_volume_monitor_get
    from /usr/local/lib/libgio-2.0.so.0
  • #11 _gtk_file_system_init
    at gtkfilesystem.c line 582
  • #12 g_type_create_instance
    from /usr/local/lib/libgobject-2.0.so.0
  • #13 g_object_new_valist
    from /usr/local/lib/libgobject-2.0.so.0
  • #14 g_object_newv
    from /usr/local/lib/libgobject-2.0.so.0
  • #15 g_object_new
    from /usr/local/lib/libgobject-2.0.so.0
  • #16 _gtk_file_system_new
    at gtkfilesystem.c line 633
  • #17 set_file_system_backend
    at gtkfilechooserdefault.c line 5076
  • #18 _gtk_file_chooser_default_init
    at gtkfilechooserdefault.c line 738
  • #19 g_type_create_instance
    from /usr/local/lib/libgobject-2.0.so.0
  • #20 g_weak_ref_get
    from /usr/local/lib/libgobject-2.0.so.0
  • #21 gtk_file_chooser_default_constructor
    at gtkfilechooserdefault.c line 4940
  • #22 g_object_new_valist
    from /usr/local/lib/libgobject-2.0.so.0
  • #23 g_object_newv
    from /usr/local/lib/libgobject-2.0.so.0
  • #24 g_object_new
    from /usr/local/lib/libgobject-2.0.so.0
  • #25 _gtk_file_chooser_default_new
    at gtkfilechooserdefault.c line 10081
  • #26 gtk_file_chooser_widget_constructor
  • #27 g_object_new_valist
    from /usr/local/lib/libgobject-2.0.so.0
  • #28 g_object_newv
    from /usr/local/lib/libgobject-2.0.so.0
  • #29 g_object_new
    from /usr/local/lib/libgobject-2.0.so.0
  • #30 gtk_file_chooser_dialog_constructor
    at gtkfilechooserdialog.c line 278
  • #31 g_object_new_valist
    from /usr/local/lib/libgobject-2.0.so.0
  • #32 g_object_new_valist
    from /usr/local/lib/libgobject-2.0.so.0
  • #33 g_object_new
    from /usr/local/lib/libgobject-2.0.so.0
  • #34 gtk_file_chooser_dialog_new_valist
    at gtkfilechooserdialog.c line 398
  • #35 IA__gtk_file_chooser_dialog_new
    at gtkfilechooserdialog.c line 442
  • #36 ??
  • #37 ??
  • #38 gtk_item_factory_callback_marshal
    at gtkitemfactory.c line 188
  • #39 g_closure_invoke
    from /usr/local/lib/libgobject-2.0.so.0
  • #40 g_signal_emitv
    from /usr/local/lib/libgobject-2.0.so.0
  • #41 g_signal_emit_valist
    from /usr/local/lib/libgobject-2.0.so.0
  • #42 g_signal_emit
    from /usr/local/lib/libgobject-2.0.so.0
  • #43 IA__gtk_widget_activate
    at gtkwidget.c line 5041
  • #44 IA__gtk_menu_shell_activate_item
    at gtkmenushell.c line 1276
  • #45 gtk_menu_shell_button_release
    at gtkmenushell.c line 703
  • #46 gtk_menu_button_release
    at gtkmenu.c line 3018
  • #47 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 86
  • #48 g_closure_invoke
    from /usr/local/lib/libgobject-2.0.so.0
  • #49 g_signal_emitv
    from /usr/local/lib/libgobject-2.0.so.0
  • #50 g_signal_emit_valist
    from /usr/local/lib/libgobject-2.0.so.0
  • #51 g_signal_emit
    from /usr/local/lib/libgobject-2.0.so.0
  • #52 gtk_widget_event_internal
    at gtkwidget.c line 5010
  • #53 IA__gtk_widget_event
    at gtkwidget.c line 4807
  • #54 IA__gtk_propagate_event
    at gtkmain.c line 2501
  • #55 IA__gtk_main_do_event
    at gtkmain.c line 1696
  • #56 gdk_event_dispatch
    at gdkevents-x11.c line 2425
  • #57 g_main_context_dispatch
    from /usr/local/lib/libglib-2.0.so.0
  • #58 g_main_context_pending
    from /usr/local/lib/libglib-2.0.so.0
  • #59 g_main_loop_run
    from /usr/local/lib/libglib-2.0.so.0
  • #60 IA__gtk_main
    at gtkmain.c line 1268
  • #61 ??
  • #62 ??
  • #63 ??
  • #64 ??
  • #0 _kevent
    from /lib/libc.so.7

Comment 9 Steven Chamberlain 2015-09-22 12:17:51 UTC
Hi!

I've already been looking at this bug in the context of the Debian glib2.0 package for GNU/kFreeBSD:  https://bugs.debian.org/bug=734290#17

As best as I could tell:

"This was introduced or exposed by:
https://git.gnome.org/browse/glib/commit/?id=548c165a9f8386af29e8bb8243d8923e0f315c2e"

I'm not so sure my analysis is correct:

"[g_unix_mount_monitor_get] waits there for the constructor to finish (effective_state->1).
But inside the constructor, it sets up a file monitor on /etc/fstab,
and that hangs waiting for the_volume_monitor_mutex already held
somewhere."

Debugging it should be much easier on actual FreeBSD, since Debian GNU/kFreeBSD's gdb wasn't able to see all threads.

I'd recommend someone running real FreeBSD to try this to see if it helps:

"commenting out that mutex in gio/gunionvolumemonitor.c
and it seem to not hang any more"

581 _g_mount_get_for_mount_path (const gchar  *mount_path,
582                              GCancellable *cancellable)
583 {

593   if (klass->get_mount_for_mount_path)
594     {
595 //      g_rec_mutex_lock (&the_volume_monitor_mutex);
596       mount = klass->get_mount_for_mount_path (mount_path, cancellable);
597 //      g_rec_mutex_unlock (&the_volume_monitor_mutex);
598     }

Thanks!
Comment 10 walter s. 2015-09-22 15:16:37 UTC
Seems to work on FreeBSD-10.2 amd64.
Comment 11 Steven Chamberlain 2015-09-22 15:40:34 UTC
If you're using glib20 port revision 2.44.1_1, it has disabled kqueue to
avoid hitting the bug, but as far as I know the problem is still there:
http://www.freshbsd.org/commit/freebsd-ports/r393663
Comment 12 walter s. 2015-09-22 15:47:53 UTC
I have not forgotten to comment out the line in glib20/Makefile and so re-enable kqueue. Here it works with (tested with Thunderbird, Firefox and Leafpad, pcmanfm starts now normal).
Comment 13 Steven Chamberlain 2015-09-22 17:19:20 UTC
Hi Walter, just to make sure I understand you...

Did you comment out the mutex as I mentioned in #9 - or is it working now unmodified with FreeBSD 10.2 amd64?
Comment 14 walter s. 2015-09-22 17:27:26 UTC
I comment out the "workaround" in glib20/Makefile and comment out the mutex as in #9 above.
Comment 15 Tomasz Sowa 2015-10-05 20:55:35 UTC
(In reply to Steven Chamberlain from comment #9)
> I'd recommend someone running real FreeBSD to try this to see if it helps:

Thanks, it works for me too:
- FreeBSD 10.2 stable amd64
- glib-2.44.1_1

Without this patch I had got a problem with file icons in file managers such as caja/thunar/pcmanfm, I had to manually press F5 to refresh icons. Also the trash didn't show any icons, now it seems to work ok.
Comment 16 Andreas Henriksson 2015-12-22 08:35:22 UTC
Created attachment 317773 [details] [review]
gio: drop obsoleted lock causing deadlocks on FreeBSD

I think it is a recursion from the GUnixMountMonitor constructor, to a
GLocalFileMonitor on /etc/fstab, and into GUnixMountMonitor again, now
with a mutex already held, so it deadlocks.
https://bugzilla.gnome.org/page.cgi?id=traceparser/trace.html&trace_id=235354

That mutex in glocalfile.c:g_local_file_find_enclosing_mount() doesn't
seem necessary any more IMHO.  Inside it, only 'mount' is modified, but
that's just a stack variable local to this function.  When
klass->get_mount_for_mount_path is called, it's given one const
parameter and the other is unused, so they're unchanged. 'klass'
doesn't seem it could be modified either inside that function.

It doesn't recurse infinitely, but seems to work correctly and pass the
testsuite after this change.

The FreeBSD project already applied my patch in their ports tree, and
their users seem happy with it.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712848#64
and
Comment 17 Allison Karlitskaya (desrt) 2015-12-23 14:40:52 UTC
If FreeBSD and Debian kfreebsd are both shipping this patch, then there is no reason for us to wait any longer.  Sorry for not noticing this until now.
Comment 18 Allison Karlitskaya (desrt) 2015-12-23 14:42:11 UTC
Attachment 317773 [details] pushed as 42b160b - gio: drop obsoleted lock causing deadlocks on FreeBSD