[Openmcl-devel] Class-initialization crash in multithreaded code on Win64/Vista 64

[Gary Byers]

On Sat, 28 May 2011, Matt Lamari wrote:

>
> I tried on the mac also but it wouldn't repeat; but is VERY repeatable
> in 64 bit windows.

It's a Windows-specific threads/GC issue.  If anyone's really interested
in the gory details, ask, but they generally arent't very interesting.

It doesn't have anything to do with instance initialization as such; you
could probably reproduce it just by having several threads that spent
most of their time consing.  (Your test case is a good one, since the
instance initialization not only conses a lot but expects that to have
actually worked ...)  In any case, your example does seem to cause the
problematic Windows-specific GC cases to occur fairly reliably and fairly
quickly, and the nonsense starts happening almost immediately after at
least one of those cases occurs.


>
> I have the latest 1.6 binary from the binary download page.
>
> This code will crash wx86cl64.exe from a clean start.
>
> Note - if you run the make-instance out of a loop, it works fine, it's
> the parallel action that triggers the error.
>
> Here is the code that crashes it, a class definition and a loop that
> starts infinite running threads that call make-instance:
>
> http://pastebin.com/sPNCcYYp
>
> It fails with an odd error message about "value 0 is not of type list"
> while running default-initargs.  This error is consistent across threads.

I saw this a few other things that were equally nonsensical.  The real error
is something like "something catastrophic happened in the GC, and memory's
in an inconsistent state."  If you do:

? (setq ccl::*gc-event-status-bits* (logior ccl::*gc-event-status-bits* 4))

then the GC will do some (a lot of ...) extra integrity checking before
and after it runs, and will enter the kernel debugger complaining about
problems that it finds.  You'll probably see those complaints before the
problems that they describe start manifesting themselves as (nonsensical)
lisp errors.

I'd thought that all of this stuff worked reliably, but I was clearly
mistaken about that.  Your test case exercises it a lot more than more
... realistic code does, so if it can be made to work that'd be a good
thing all around.

>
> If the code looks familiar, it is isolated from the gzip-stream library.
> . .
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>