[Openmcl-devel] Alpha-testing 0.14

[Gary Byers]

On Fri, 28 Feb 2003, Yannick Versley wrote:

> I've found another bug:
>
> (compile-file "nregex.lisp")
> (load "nregex.dfsl")
> (nregex:regex-compile "\\(")
> gets you an unhandled Exception 4 with the current cvs Pre_0_14.
>
> If you just load the .lisp file, nothing special happens.
>
> The file is from maxima, a computer algebra system which works fine under
> openmcl 0.13.

Thanks.

I've been looking at Portable Allegroserve (which also includes an
"nregex.lisp" - not sure if it's the same one), and it dies with
all kinds of nasty symptoms during compilation/loading (even if it's
conditionalized for thread changes.)

The good news is that (so far) this doesn't seem to be a subtle thread-
related bug: something seems to be scribbling over already-allocated
memory, but it all seems to be happening in the original listener thread.

One thing that can be done to catch things like this early is to force
the GC to do some extra integrity checking:

? (setq ccl::*GC-EVENT-STATUS-BITS* 4)

That'll cause the GC to slow down substantially, and run fairly rigorous
consistency checks on things before and after it does its usual work.
(If it finds an inconsistency, it'll trap into the low-level debugger
with a message that usually complains about missing/unexpected/invalid
headers.)

In the paserve case, it catches the memory corruption on entry to the
first GC (after half a dozen or so files - including nregex - have been
loaded.)

If something's scribbling over previously allocated memory, that can
certainly lead to all sorts of problems; the GC usually makes those
problems worse.

Hopefully, this is something mundane and easily fixed (and ideally the
nregex problem and the paserve problem are the same.)

Thanks.



_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel