using gmodule causes strange lockup

[Evan Martin <martine cs washington edu>]

I recently got a patch to change some code from using dlopen() to using
the gmodule equivalents.  The code looks good (it's pretty simple), yet
after I applied it the program started locking on startup.

What's weirder, is that the lockup is outside of the gmodule code, and
it looks like it's related to threads.

Here's a backtrace from when it is locked:

(gdb) attach 2564
Attaching to process 2564
Reading symbols from
/home/martine/projects/logjam/logjam/src/logjam...done.
[...]
(gdb) bt
#0  0x405efce2 in sigsuspend () from /lib/libc.so.6
#1  0x40cab6df in __pthread_wait_for_restart_signal () from
/lib/libpthread.so.0
#2  0x40cad36e in __pthread_alt_lock () from /lib/libpthread.so.0
#3  0x40ca9f99 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x40cac566 in flockfile () from /lib/libpthread.so.0
#5  0x406f5d3a in istream & operator>><char, string_char_traits<char>,
__default_alloc_template<true, 0> > () from
/usr/lib/libstdc++-libc6.2-2.so.3
#6  0x40dd8f66 in _Bit_iterator fill_n<_Bit_iterator, unsigned int,
bool> ()
   from /usr/lib/libaspell.so.10
#7  0x40dd8f90 in _Bit_iterator fill_n<_Bit_iterator, unsigned int,
bool> ()
   from /usr/lib/libaspell.so.10
#8  0x40dd8f90 in _Bit_iterator fill_n<_Bit_iterator, unsigned int,
bool> ()
   from /usr/lib/libaspell.so.10
#9  0x40dd8f90 in _Bit_iterator fill_n<_Bit_iterator, unsigned int,
bool> ()
   from /usr/lib/libaspell.so.10
#10 0x40dda049 in autil::load_phonet_rules () from
/usr/lib/libaspell.so.10
#11 0x40d915b1 in aspell::new_soundslike () from
/usr/lib/libaspell.so.10
#12 0x40d8cf82 in aspell::Language::setup () from
/usr/lib/libaspell.so.10
#13 0x40d9bb51 in aspell::DataSet::set_check_lang () from
/usr/lib/libaspell.so.10
#14 0x40da65cd in aspell_default_readonly_ws::ReadOnlyWS::load ()
   from /usr/lib/libaspell.so.10
#15 0x40d9f7c0 in aspell::add_data_set () from /usr/lib/libaspell.so.10
#16 0x40dd31a8 in aspell::MultiWS::load () from /usr/lib/libaspell.so.10
#17 0x40d9f7c0 in aspell::add_data_set () from /usr/lib/libaspell.so.10
#18 0x40db8f59 in aspell::Manager::real_setup () from
/usr/lib/libaspell.so.10
#19 0x40db8cee in aspell::Manager::setup () from
/usr/lib/libaspell.so.10
#20 0x40d1b8d2 in pspell_aspell::PA_Manager::PA_Manager ()
   from /usr/lib/libpspell_aspell.so.2
#21 0x40d1cde3 in libpspell_aspell_LTX_new_pspell_manager_class ()
   from /usr/lib/libpspell_aspell.so.2
#22 0x4010125d in new_pspell_manager_class () from
/usr/lib/libpspell.so.4
#23 0x40102f63 in new_pspell_manager () from /usr/lib/libpspell.so.4
#24 0x400e7ea8 in build_suggestion_menu () from
/usr/lib/libgtkspell.so.0
#25 0x400e819b in gtkspell_new_attach () from /usr/lib/libgtkspell.so.0
#26 0x0805f1c0 in make_main_entry (ljw=0x8103088) at lj.c:473
#27 0x0805f4e6 in make_app_contents (ljw=0x8103088) at lj.c:537
#28 0x0805f864 in lj_run (entry=0x80ef040) at lj.c:652
#29 0x080535b2 in main (argc=1, argv=0xbffffaa4) at init.c:372

If I remove the call to g_module_open (which happens before this
lockup), the lockup goes away.  (Varying the G_MODULE_BIND_LAZY flag
passed to g_module_open() does not seem to affect whether it locks.)

The lockup seems related to a pthread mutex.
My code does not use any threads, and gmodule doesn't seem to want any
thread-related options while compiling:
$ pkg-config --cflags --libs gmodule-2.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -Wl,--export-dynamic
-lgmodule-2.0 -ldl -lglib-2.0

Nor does aspell mention any special pthread-related command-line arguments:
http://savannah.gnu.org/download/aspell/manual/user/6_Writing.html


So why might cause this?  Should I be blaming libaspell?  What about
gmodule is making this lock when dlopen isn't?

-- 
      Evan Martin
martine cs washington edu
  http://neugierig.org