Finally I've found some time to tackle it. I've reproduced this error on
32bit ubuntu LTS and tomorrow I'll try to spot a bug. Sorry for such a
long delay.
Regards,
Daniel
James M. Lawrence writes:
> On Wed, Sep 2, 2015 at 3:32 PM, Daniel Kochmański
>> Ok, so I guess I'll just set up 32-bit VM.
On Wed, Sep 2, 2015 at 3:32 PM, Daniel Kochmański
> Ok, so I guess I'll just set up 32-bit VM. I hope this will be able to
> reproduce the problems (next test doesn't fail neither on my x86_64 for
> my tests). Yeah, I also think that kernel bug is unlikely, but I'll keep
> that possibility in mind.
On Wed, Sep 2, 2015 at 3:32 PM, Daniel Kochmański wrote:
> Ok, so I guess I'll just set up 32-bit VM. I hope this will be able to
> reproduce the problems (next test doesn't fail neither on my x86_64 for
> my tests).
It may be easier to install a 32-bit compiler and toolchain, then
build ECL with
James M. Lawrence writes:
> On Wed, Sep 2, 2015 at 6:09 AM, Daniel Kochmański
> wrote:
>> Hm, then I can't reproduce neither of them. Spawning too many threads
>> blows the heap, but it's understandable. I think it might be that i have
>> x86_64 and a new kernel, (maybe it happens only on x86,
On Wed, Sep 2, 2015 at 6:09 AM, Daniel Kochmański wrote:
> Hm, then I can't reproduce neither of them. Spawning too many threads
> blows the heap, but it's understandable. I think it might be that i have
> x86_64 and a new kernel, (maybe it happens only on x86, or linux 3.2 had
> some bug?).
64-b
Hm, then I can't reproduce neither of them. Spawning too many threads
blows the heap, but it's understandable. I think it might be that i have
x86_64 and a new kernel, (maybe it happens only on x86, or linux 3.2 had
some bug?).
You can track this issue here:
https://gitlab.com/embeddable-common-li
The version with a homemade semaphore is
(defstruct sema
(count 0)
(lock (mp:make-lock :recursive nil))
(cvar (mp:make-condition-variable)))
(defun inc-sema (sema)
(mp:with-lock ((sema-lock sema))
(incf (sema-count sema))
(mp:condition-variable-signal (sema-cvar sema
(defun d
On Tue, 01 Sep 2015 07:29:00 +0200
Daniel Kochmański wrote:
> Ok, it failed (just after sending an e-mail, it's good to know that
> Muprhy's law still works :-)).
A complete hang?
--
Matt
On Tue, 01 Sep 2015 07:25:37 +0200
Daniel Kochmański wrote:
> btw, it doesn't hang on my machine (runs ~30m already, if it'll
> fail I'll let you know). Could you provide more details? (OS,
> *features*, number of cores etc.)
I also have been trying to reproduce it on NetBSD/amd64 with 4 cores i
Ok, it failed (just after sending an e-mail, it's good to know that
Muprhy's law still works :-)).
Daniel
Daniel Kochmański writes:
> Hello,
>
> that's probably my fault, sorry. I've migrated bugs manually and
> probably missed this one (I remember this bug! but can't find anywhere).
>
> I'm add
btw, it doesn't hang on my machine (runs ~30m already, if it'll
fail I'll let you know). Could you provide more details? (OS,
*features*, number of cores etc.)
Daniel
Daniel Kochmański writes:
> Hello,
>
> that's probably my fault, sorry. I've migrated bugs manually and
> probably missed this o
Hello,
that's probably my fault, sorry. I've migrated bugs manually and
probably missed this one (I remember this bug! but can't find anywhere).
I'm adding it to regression tests in repository, thanks! Yes, old
reports are unfortunately lost.
As a sienote, please use ecl-devel@common-lisp.net m
12 matches
Mail list logo
