Re: gmodule mutex deadlock problem

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hallo,

> 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).

Thanks for fixing that. Another miracle of autoconf not fully understood by
mere mortals like me (ok, it's not that hard to understand, but remembering it
before using it seems to be to much for me)

Happy New Year,
Sebastian
-- 
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi