Hi,
Andy Wingo writes:
> On Sun 13 Feb 2011 10:58, Neil Jerram writes:
>
>> No. But that might be because the libgc on that machine - Debian
>> 1:7.1-3 - is too old. What is the latest recommendation for libgc
>> version? README says "at least version 7.0", but I suspect that's out
>> of dat
On Sun 13 Feb 2011 22:12, Neil Jerram writes:
> So I'd guess the question of which libgc version is best, is something
> we can live with for 2.0 - until more data points emerge. Right?
Yes, I think that's (unfortunately) right.
Andy
--
http://wingolog.org/
Andy Wingo writes:
> On Sun 13 Feb 2011 10:58, Neil Jerram writes:
>
>> No. But that might be because the libgc on that machine - Debian
>> 1:7.1-3 - is too old. What is the latest recommendation for libgc
>> version? README says "at least version 7.0", but I suspect that's out
>> of date.
>
On Sun 13 Feb 2011 10:58, Neil Jerram writes:
> No. But that might be because the libgc on that machine - Debian
> 1:7.1-3 - is too old. What is the latest recommendation for libgc
> version? README says "at least version 7.0", but I suspect that's out
> of date.
I think we are a little incoh
Andy Wingo writes:
>>> Neil Jerram writes:
>>>
My nightly build of master, on a relatively slow old machine, is
hanging, on most nights, in `make check'.
>>
>> The hang seems to be caused by one thread (A) running (gc) at the same
>> time as another thread (B) is doing GC_malloc_atomic
Hi Neil,
I realize this was an old message, but it didn't seem that the thread
came to a conclusion:
On Fri 24 Sep 2010 00:40, Neil Jerram writes:
>> Neil Jerram writes:
>>
>>> My nightly build of master, on a relatively slow old machine, is
>>> hanging, on most nights, in `make check'.
>
> Th
l...@gnu.org (Ludovic Courtès) writes:
> Could you run the program that I posted and report back?
That program runs fine for me - except only 100% because I have a single
core.
I also modified it to add continual thread creation and destruction
(attached), and it was still fine.
Any further ide
Hi!
Mike Gran writes:
>> However, I cannot reproduce the problem with a stock 7.1 and a recent
>
>> CVS libgc on x86_64-linux-gnu.
>
> FWIW, threads.test hangs on my box as well. Before it was only
> occasionally, but, lately it seems to happen all the time.
Could you run the program that I p
> However, I cannot reproduce the problem with a stock 7.1 and a recent
> CVS libgc on x86_64-linux-gnu.
FWIW, threads.test hangs on my box as well. Before it was only
occasionally, but, lately it seems to happen all the time.
-Mike
Hi Neil,
Neil Jerram writes:
> Neil Jerram writes:
>
>> Neil Jerram writes:
>>
>>> My nightly build of master, on a relatively slow old machine, is
>>> hanging, on most nights, in `make check'.
>>
>> FWIW, I realized that my backtraces are very similar to those reported
>> by Dale here:
>> htt
;s already fixed upstream; I haven't tried to check that yet.
Regards,
Neil
>From 6013922c08c35a4e1051d4481d5bb4580bda1430 Mon Sep 17 00:00:00 2001
From: Neil Jerram
Date: Thu, 23 Sep 2010 23:13:39 +0100
Subject: [PATCH] Workaround for hang in threads.test
---
test-suite/tests/threads.te
Neil Jerram writes:
> Neil Jerram writes:
>
>> My nightly build of master, on a relatively slow old machine, is
>> hanging, on most nights, in `make check'.
>
> FWIW, I realized that my backtraces are very similar to those reported
> by Dale here:
> http://www.mail-archive.com/bug-gu...@gnu.org/
Neil Jerram writes:
> My nightly build of master, on a relatively slow old machine, is
> hanging, on most nights, in `make check'.
FWIW, I realized that my backtraces are very similar to those reported
by Dale here:
http://www.mail-archive.com/bug-gu...@gnu.org/msg05066.html.
So I'll try to ans
My nightly build of master, on a relatively slow old machine, is
hanging, on most nights, in `make check'. The tail of check-guile.log
says
PASS: threads.test: mutex-ownership: mutex ownership for unlocked mutex
PASS: threads.test: mutex-ownership: locking mutex on behalf of other thread
PASS: th
14 matches
Mail list logo
