On Sat, Mar 31, 2012 at 12:13 PM, Matthew Mondor <mm_lists@pulsar-zone.net> wrote:
It appears that it locks before all initial threads of the HTTPd can be
started.  The REPL doesn't come back while that thread appears to be
waiting on a pthread_cond_wait(3) forever without getting an event.
This happens inside the GC, invoked sometime during HTTPD-INIT (that
happens in the first/main thread):

#0  0x00007f7ff6a76eda in ___lwp_park50 () from /usr/lib/libc.so.12
#1  0x00007f7ff72088f4 in pthread_cond_timedwait (abstime=0x0, mutex=0x7f7ff7b010e8, cond=0x7f7ff7b01118) at /usr/src/lib/libpthread/pthread_cond.c:148
#2  pthread_cond_wait (cond=0x7f7ff7b01118, mutex=0x7f7ff7b010e8) at /usr/src/lib/libpthread/pthread_cond.c:193
#3  0x00007f7ff7205cc1 in sem_wait (sem=0x7f7ff60408f0) at /usr/src/lib/libpthread/sem.c:323
#4  0x00007f7ff5e187d8 in GC_stop_world () from /usr/pkg/lib/libgc.so.1

This is where the garbage collector tries to suspend all threads that were running and registered with it. It is waiting probably for the ok from every thread but...

As for the other successfully-started threads (there are 9 of these,
8 of which are waiting in sigsuspend(2)) after an attempt to obtain the
global accept-lock unsuccessfully (as the first thread acquired it).

#0  0x00007f7ff6a38eca in _sys___sigsuspend14 () from /usr/lib/libc.so.12
#1  0x00007f7ff7206732 in __sigsuspend14 (sigmask=<optimized out>) at /usr/src/lib/libpthread/pthread_cancelstub.c:567
#2  0x00007f7ff777f341 in ecl_wait_on (env=0x7f7ff7ed8000, condition=0x7f7ff777105a <get_lock_inner>, o=0x28b5f90)

... somehow these threads did not respond to the signal. I do not really understand it. Was it before a change I did recently? ECL now _only_ blocks its communication signal in sigsuspend(). It should not be blocking the signal from the garbage collector.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)