Re: OpenMCL 1.0 (up to head) memory corruption

I was able to reproduce this once (and am on a second iteration).

I still don't know exactly what's going on, but have noticed that
even with *really-write-files* set to NIL, the clients get way
ahead of the server; :PROC in the client indicates that all of
the client threads are waiting for the server to read prior
output (in other words, the server threads aren't getting much
of any work done.)

David Rager ran into something last week where a a large number
of threads - each doing incidental memory allocation - triggered
nearly constant GCs.  (This has to do with the way that per-thread
memory-allocation works and with the fact that the mechanism used
by the GC to stop threads causes blocking system calls to fail;
retrying the system call did incidental memory allocation, which
triggered a GC, which interrupted blocking system calls ...)

As bad as that was/is, what sometimes happened is that sometimes
newly-awakened (after GC) threads would trigger a GC before all
of their peers had finished waking up after the previous GC.  That's
bad (for a number of reasons), and I think that the one crash that
I saw in your test case -may- have something to do with that.

In David's case, we worked around the issue by ensuring that one
particular primitive (TIMED-WAIT-ON-SEMAPHORE) avoided the incidental
consing that led to the hysteria.  Another short-term workaround was
to disable the EGC or set its thresholds high enough that it's not
triggered as often.

In the one test case that I've had fail so far, it was the server that
crashed and which had entered some non-productive state before crashing.
Has that been your experience, or have you seen crashes in the client
as well ?


On Mon, 30 Jan 2006, rs wrote:

> Hi,
> I experience crashes when mcl runs a long time or with a lot of multithreaded 
> tasks.
> To test this, i wrote two small apps, an remote eval server and a server 
> receiving files whose code is attached to this mail.
>
>
>
>