Re: Threads deadlock in select

[Andy Wingo]

Hi Andrew,

Sorry for the late reply.

On Fri 02 Sep 2011 16:29, Andrew Gaylard <address@hidden> writes:

> (gdb) bt
> #0  0xfffffd7ffe89c257 in __lwp_park () from /lib/64/libc.so.1
> #1  0xfffffd7ffe8941f6 in mutex_lock_queue () from /lib/64/libc.so.1
> #2  0xfffffd7ffe894ca8 in mutex_lock_impl () from /lib/64/libc.so.1
> #3  0xfffffd7ffe894d9b in pthread_mutex_lock () from /lib/64/libc.so.1
> #4  0xfffffd7ffec20bf8 in scm_pthread_mutex_lock (mutex=0xfffffd7ffec62090) 
> at threads.c:1499
> #5  0xfffffd7ffebc1d2e in scm_gc_for_newcell (freelist=0xfffffd7ffec686e0, 
> free_cells=0x478e08) at gc.c:484
> #6  0xfffffd7ffebd7169 in scm_cell (car=8112048, cdr=1028) at 
> ../libguile/inline.h:122
> #7  0xfffffd7ffebd8461 in scm_list_1 (e1=0x7bc7b0) at list.c:47
> #8  0xfffffd7ffebef712 in scm_remove_from_port_table (port=0x7bc7b0) at 
> ports.c:564
> #9  0xfffffd7ffebc545b in scm_i_sweep_card (p=0x7bc7b0, 
> free_list=0xfffffd7fffdfd2d8, seg=0x4ccde0) at gc-card.c:212
> #10 0xfffffd7ffebc3a7a in scm_i_sweep_some_cards (seg=0x4ccde0) at 
> gc-segment.c:168
> #11 0xfffffd7ffebc4042 in scm_i_sweep_some_segments (fl=0xfffffd7ffec686e0) 
> at gc-segment.c:353
> #12 0xfffffd7ffebc1d54 in scm_gc_for_newcell (freelist=0xfffffd7ffec686e0, 
> free_cells=0x478e08) at gc.c:487
> #13 0xfffffd7ffebd7169 in scm_cell (car=6192256, cdr=1028) at 
> ../libguile/inline.h:122
> #14 0xfffffd7ffebee29b in scm_cons (x=0x5e7c80, y=0x404) at pairs.c:62
...

> #0  0xfffffd7ffe8a162a in __pollsys () from /lib/64/libc.so.1
> #1  0xfffffd7ffe88fa45 in _pollsys () from /lib/64/libc.so.1
> #2  0xfffffd7ffe848334 in pselect () from /lib/64/libc.so.1
> #3  0xfffffd7ffe848602 in select () from /lib/64/libc.so.1
> #4  0xfffffd7ffec20ad4 in scm_std_select (nfds=13, 
> readfds=0xfffffd7ffe3dba20, writefds=0x0, exceptfds=0xfffffd7ffe3d9a20, 
> timeout=0x0) at threads.c:1465
> #5  0xfffffd7ffec395e9 in scm_accept (sock=0x7cec80) at socket.c:1346
> #6  0xfffffd7ffebb0a3e in ceval (x=0x404, env=0x83bdc0) at eval.c:4232

It seems that `accept' in 1.8 was not called in a scm_without_guile, so
Guile thinks that thread is still active, and thus the code that tries
to shut down all threads can't grab its thread lock.

Some solutions that I can think of:

  * Patch scm_accept to leave Guile.  (Then submit the patch :)

  * Do a `select' on the socket before accepting, to be sure there's a
    client ready, and that `accept' won't block.

  * Port to Guile 2.0.

> We can't upgrade to 2.0.x, as I can't get it to build on our platform
> (Solaris-10, SPARC and x86-64).  Tips on that'd be helpful too.

I think we have had some reports of Guile 2.0 building on this platform,
but it's not a regular build platform.  If you are interested in getting
this to work, send build logs for Guile 2.0.3 to address@hidden

Thanks,

ANdy
-- 
http://wingolog.org/