Bug#734290: kfreebsd-amd64: monitor test hangs in _kqueue_thread_func()

Steven Chamberlain steven at pyro.eu.org
Mon Jun 15 15:59:11 UTC 2015


found 734290 glib2.0/2.43.92-1
found 734290 glib2.0/2.44.1-1
tags 734290 - patch
thanks

Hi,

Robert Millan wrote:
> monitor test hangs when running the testsuite on kfreebsd-amd64 (using glibc 2.18).

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

We can't really ignore this test failure as it seems any caller of
g_unix_mount_monitor_get() gets stuck in the g_cond_wait() loop.

| ...
| #2  0x000000080108426c in g_cond_wait (cond=cond at entry=0x800b9f250 <mount_monitor_group+16>, mutex=mutex at entry=0x800b9f248 <mount_monitor_group+8>)
|     at /home/steven/glib2.0-2.44.1/./glib/gthread-posix.c:767
|         _g_boolean_var_ = <optimized out>
|         status = <optimized out>
| #3  0x000000080085dbe3 in g_context_specific_group_request_state (group=0x800b9f240 <mount_monitor_group>, requested_state=<optimized out>, 
|     requested_func=<optimized out>) at /home/steven/glib2.0-2.44.1/./gio/gcontextspecificgroup.c:157
| No locals.

153   /* we only block for positive transitions */
154   if (requested_state)
155     {
156       while (group->requested_state != group->effective_state)
157         g_cond_wait (&group->cond, &group->lock);

| #4  0x000000080085dca3 in g_context_specific_group_get (group=group at entry=0x800b9f240 <mount_monitor_group>, type=<optimized out>, 
|     context_offset=context_offset at entry=24, start_func=start_func at entry=0x8008c03a0 <mount_monitor_start>)
|     at /home/steven/glib2.0-2.44.1/./gio/gcontextspecificgroup.c:202
|         css = 0x60f6b0
|         context = 0x616340
| #5  0x00000008008c16c8 in g_unix_mount_monitor_get () at /home/steven/glib2.0-2.44.1/./gio/gunixmounts.c:1557
| No locals.

1554 GUnixMountMonitor *
1555 g_unix_mount_monitor_get (void)
1556 {
1557   return g_context_specific_group_get (&mount_monitor_group,
1558                                        G_TYPE_UNIX_MOUNT_MONITOR,
1559                                        G_STRUCT_OFFSET(GUnixMountMonitor, context),
1560                                        mount_monitor_start);
1561 }

It 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.  I'll post a stack trace of that in a followup.

I tried commenting out that mutex in gio/gunionvolumemonitor.c
and it seem to not hang any more, and pass the gio/volumemonitor tests
at least:

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     }

Regards,
-- 
Steven Chamberlain
steven at pyro.eu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 493 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20150615/86ee0200/attachment.sig>


More information about the pkg-gnome-maintainers mailing list