Re: gmodule mutex deadlock problem

[Martin Baulig <martin home-of-linux org>]

Tim Janik <timj gtk org> writes:

> On 28 Dec 2000, Martin Baulig wrote:
> 
> > there's a bug in gmodule which causes a deadlock when
> > threads are enabled:
> > 
> > The problem is that g_module_open() calls g_module_symbol()
> > while holding a lock on the g_module_global_lock._
> 
> eh? that shouldn't be the problem as g_module_global_lock is a
> recursive mutex (though maybe there're prblems with recursive
> mutexes, dunno). could you give a more detailed description
> of how to trigger this (and please Cc: Sebastian on that
> as he's our threading guru ;).

Ok, after some debugging I finally found the problem.

In configure.in in line 1114 we have:

---
glib_cv_sizeof_system_thread=`expr $glib_cv_sizeof_system_thread + $ac_cv_sizeof_long`
---

This is wrong, you cannot modify a cache variable in this way. Next time
configure is run without deleting config.cache (for instance, from
config.status --recheck), glib_cv_sizeof_system_thread already has the
incremented value and gets incremented another time.

Btw. there's also another bug with this, it doesn't even work the first time
configure is run; I end up having GLIB_SIZEOF_SYSTEM_THREAD == 4, but
glib_cv_sizeof_system_thread == 8 (because it is already AC_DEFINE'd before
this expression).

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)