Re: 1.8 make check failing in popen.test

[Rob Browning]

Rob Browning <address@hidden> writes:

> Kevin Ryde <address@hidden> 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