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

2015-09-22 Thread Steven Chamberlain
forwarded 734290 https://bugzilla.gnome.org/show_bug.cgi?id=753378
thanks

Also:  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202128
FreeBSD disabled kqueue in their Makefile as a workaround for this:

-CONFIGURE_ENV= ac_cv_header_sys_inotify_h=
+CONFIGURE_ENV= ac_cv_header_sys_inotify_h= \
+   ac_cv_header_sys_event_h=

https://docs.freebsd.org/cgi/getmsg.cgi?fetch=2002311+0+/usr/local/www/mailindex/archive/2015/svn-ports-head/20150809.svn-ports-head

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature


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

2015-06-15 Thread Steven Chamberlain
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  0x00080108426c in g_cond_wait (cond=cond@entry=0x800b9f250 
mount_monitor_group+16, mutex=mutex@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  0x00080085dbe3 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  0x00080085dca3 in g_context_specific_group_get 
(group=group@entry=0x800b9f240 mount_monitor_group, type=optimized out, 
| context_offset=context_offset@entry=24, 
start_func=start_func@entry=0x8008c03a0 mount_monitor_start)
| at /home/steven/glib2.0-2.44.1/./gio/gcontextspecificgroup.c:202
| css = 0x60f6b0
| context = 0x616340
| #5  0x0008008c16c8 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,
1558G_TYPE_UNIX_MOUNT_MONITOR,
1559G_STRUCT_OFFSET(GUnixMountMonitor, 
context),
1560mount_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
ste...@pyro.eu.org


signature.asc
Description: Digital signature