Stanislav Ievlev <stanislav.iev...@gmail.com> writes:
> It's very strange but I see an only one thread. full Backtrace in attach.
That is indeed odd. Are you using GDB, and the "info threads"
command, and it lists only one thread?
> > #0 0x00002b4ba31b4004 in __lll_lock_wait () from /lib64/libpthread.so.0
> > #1 0x00002b4ba31af944 in _L_lock_55 () from /lib64/libpthread.so.0
> > #2 0x00002b4ba31af341 in pthread_mutex_lock () from /lib64/
> libpthread.so.0
> > #3 0x00002b4ba22f87dc in scm_i_thread_put_to_sleep () from /usr/lib64/
> > libguile.so.17
> > #4 0x00002b4ba22abfd9 in scm_i_gc () from /usr/lib64/libguile.so.17
> > #5 0x00002b4ba22ac338 in scm_gc_for_newcell () from /usr/lib64/
> libguile.so.17
> > #6 0x00002b4ba22cc86f in scm_cons () from /usr/lib64/libguile.so.17
This backtrace indicates the GC thread trying to lock the "heap mutex"
of all other threads (however many there are), and blocking on one of
those.
(Or possibly the thread_admin_mutex. Can you get line numbers and
match those against your source code, to see if the relevant line in
scm_i_thread_put_to_sleep is
scm_i_pthread_mutex_lock (&thread_admin_mutex);
or
scm_i_pthread_mutex_lock (&t->heap_mutex);
?)
This could happen if your application has another thread that is in
Guile mode but has blocked on something - e.g. select, read, locking
another mutex. Is that possible?
Regards,
Neil
