Rob Browning <[EMAIL PROTECTED]> writes: > Kevin Ryde <[EMAIL PROTECTED]> writes: > >> I suppose that's the killer, a port gc-ed prematurely. Perhaps >> there'd be some significance in which one it was. port-for-each >> looks pretty safe, maybe the port table has gone bad earlier. > > I think I found the problem. I believe scm_c_port_for_each() needs a > call to scm_remember_upto_here_1(ports) at the end.
Apparently I spoke too soon, or rather, that wasn't the only problem. Though the child is no longer segfaulting, popen.test still hangs occasionally. I caught it hanging between two debug statements with nothing between them other than a (gc) statement I added. So I tried attaching gdb to the child (which is still in open-process, a bit after the fork), and saw: #0 0xffffe410 in __kernel_vsyscall () #1 0x401b655e in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x401b318d in _L_mutex_lock_29 () from /lib/tls/i686/cmov/libpthread.so.0 #3 0xbf83b568 in ?? () #4 0x400b41b9 in scm_leave_guile () at threads.c:369 #5 0x400b423b in scm_i_thread_put_to_sleep () at threads.c:1538 #6 0x40060c69 in scm_i_gc (what=0x400d2dcb "call") at gc.c:548 #7 0x40060e81 in scm_gc () at gc.c:454 An strace also indicates that the child is blocked on a futex call. Looking at threads.c, at that that point Guile is calling scm_i_pthread_mutex_unlock() from within scm_leave_guile(). I imagine that pthread_mutex_unlock() is making the call to lock a lower level mutex, which blocks. At the moment, though, I don't why it blocks. I wonder if the parent left that mutex in an unexpected state when it forked. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
