Rob Browning <[EMAIL PROTECTED]> writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> Will etch have guile 1.6 as well, or would this upload replace guile
>> 1.6?
>
> This won't affect the guile-1.6 packages.
Thanks for confirming that.
Regards,
Neil
___
Neil Jerram <[EMAIL PROTECTED]> writes:
> Will etch have guile 1.6 as well, or would this upload replace guile
> 1.6?
This won't affect the guile-1.6 packages.
> That would be serious. Presumably lilypond doesn't require threads
> then?
I would assume so, since the lilypond maintainer's very m
Rob Browning <[EMAIL PROTECTED]> writes:
> On a related topic, in order for Guile 1.8 to make it into Debian etch
> (the upcoming stable release), we're essentially out of time to fix
> this problem. Because of this I'm contemplating uploading the initial
> Guile 1.8 packages with --with-threads=
Rob Browning <[EMAIL PROTECTED]> writes:
> Though not conclusive, these results, when combined with the gdb
> backtrace I posted earlier showing the blockage in scm_gc() while
> trying to lock a a mutex, seem to suggest that the remaining problem
> is thread related.
On a related topic, in order
Rob Browning <[EMAIL PROTECTED]> writes:
> In any case, I'll see if I can still get it to hang using
> --without-threads.
I have a tree here where I added a (gc) call before and after the
port-for-each call in popen.scm (in the child). Given that and
--with-threads=yes, "make check" would hang e
Marius Vollmer <[EMAIL PROTECTED]> writes:
> Yes. I think I have been here when investigating the popen blocking
> problem, but then I compiled Guile without thread support and I could
> still observe the blocking. (I stopped at that point, lazy me, but
> debugging should have been simpler witho
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Rob Browning <[EMAIL PROTECTED]> writes:
>>
>> I believe a while back I wondered if we might have trouble with
>> pthreads and fork unless we were very careful, and I'm beginning to
>> wonder again.
>
> Ahh, that sounds likely. If mutexes are unusable once
Rob Browning <[EMAIL PROTECTED]> writes:
>
> I believe a while back I wondered if we might have trouble with
> pthreads and fork unless we were very careful, and I'm beginning to
> wonder again.
Ahh, that sounds likely. If mutexes are unusable once forked then
that'd hurt the gc trying to get all
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Sound bizarre. Maybe hacking scm_i_pthread_mutex_init to force the
> use of the "error checking" mutex attribute and then hacking
> scm_i_pthread_mutex_lock and scm_i_pthread_mutex_unlock to check the
> return and errno would show something. Dunno what th
Rob Browning <[EMAIL PROTECTED]> writes:
>
> 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.
Sound bizarre. Maybe hacking scm_i_pthread_mutex_init to force the
use of the "error checking" mutex attribute and then hacki
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
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()
Rob Browning <[EMAIL PROTECTED]> writes:
>
> ;;(dbg-out (list 'pt-entry pt-entry))
> ...
>
> ERROR: popen.test: open-output-pipe: no duplicate - arguments:
> ((wrong-type-arg "list-copy" "Wrong type argument in position ~A: ~S"
>
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Looks about right. What's the child process doing? It's supposed to
> be writing to the parent to say continue. (Unless it failed to fork
> there should be some child, either running or a zombie.)
(Consider the following info preliminary. I haven't had
Rob Browning <[EMAIL PROTECTED]> writes:
> Hmm. Just to be sure, I started off with a completely fresh tree, and
> now it hangs with the original code, and fails like this with your
> replacement code:
>
> Running popen.test
> FAIL: popen.test: open-output-pipe: no duplicate
> Running ports
Rob Browning <[EMAIL PROTECTED]> writes:
> OK, here's what I see with that test code:
>
> Running popen.test
> FAIL: popen.test: open-output-pipe: no duplicate
> FAIL: popen.test: close-pipe: exit 0
> ERROR: popen.test: close-pipe: exit 1 - arguments: ((wrong-number-of-args #f
> "Wrong number of
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Actually, I see the signalling pipe is left in the parent, so if the
> child has printed nothing it could hang. Obviously there's something
> wrong if the child doesn't print what's expected, but the change below
> should at least cause an error instead of
Rob Browning <[EMAIL PROTECTED]> writes:
>
>>From the output of ps auxf, it looks like the child is probably one of
> these zombies. There are several zombie sh children:
>
> \_ [sh]
> \_ [sh]
> \_ [sh]
> \_ [lt-guile]
> \_ [lt-guile]
Actually, I see the signall
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Looks about right. What's the child process doing? It's supposed
> to be writing to the parent to say continue. (Unless it failed to
> fork there should be some child, either running or a zombie.)
>From the output of ps auxf, it looks like the child is
Rob Browning <[EMAIL PROTECTED]> writes:
>
> I haven't had a chance to investigate much further yet, but if I run
> make check under gdb and hit Ctrl-C while popen.test is hung, there
> are two threads that were running.
Looks about right. What's the child process doing? It's supposed to
be writ
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I guess a select hang is probably the read-char waiting for the
> child to signal to the parent that it (the child) has closed stdout
> so the parent can go ahead and test that connection (for eof).
> Maybe gdb or some printfs can show if that's so.
I have
Rob Browning <[EMAIL PROTECTED]> writes:
>
> Ahh, I didn't notice that. It's actually the second.
I guess a select hang is probably the read-char waiting for the child
to signal to the parent that it (the child) has closed stdout so the
parent can go ahead and test that connection (for eof). May
Kevin Ryde <[EMAIL PROTECTED]> writes:
>> I've looked at the process in gdb after it hangs, and it appears to be
>> blocked in a select waiting in (I think) the "no duplicate" test.
>
> There two of those tests, which does it seem to be? (The child
> processes are different in each, "ps" might sh
Rob Browning <[EMAIL PROTECTED]> writes:
>
>mv guile-1.8.0 foo-1.8.0
Sounds bizarre.
> I've looked at the process in gdb after it hangs, and it appears to be
> blocked in a select waiting in (I think) the "no duplicate" test.
There two of those tests, which does it seem to be? (The child
pr
Rob Browning <[EMAIL PROTECTED]> writes:
> Right now 1.8's make check fails here in popen.test:
I have some further information, and it's quite surprising.
At this point with a fresh guile-1.8.0 tree, popen.test no longer
fails during make check, it hangs, but only in *some* trees. If the
tree
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Beside the test counts (which I find useful), running all the
> scripts in a single process increases the chance of catching nasty
> bugs, as you noticed. ;-) So I think it makes sense to keep it as
> is.
Hmm. While I can see the point that running
Hi,
Rob Browning <[EMAIL PROTECTED]> writes:
> Kevin Ryde <[EMAIL PROTECTED]> writes:
>> I suppose you lose the aggregated tests counts at the end. If all
>> tests work (which is presumably the normal case!) I guess it doesn't
>> matter much either way.
>
> I wonder if those test counts are act
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Seems ok for me.
I wonder if it might be a Debian unstable issue...
> I suppose you lose the aggregated tests counts at the end. If all
> tests work (which is presumably the normal case!) I guess it doesn't
> matter much either way.
I wonder if those te
Rob Browning <[EMAIL PROTECTED]> writes:
>
> FAIL: popen.test: open-input-pipe: echo hello
Seems ok for me.
> Also, while looking around, I noticed that many of our tests don't
> place themselves in a their own test module, and that raised two
> questions:
>
> 1) Should they (to limit the cha
29 matches
Mail list logo
