[Openmcl-devel] Alpha-testing 0.14

[Gary Byers]

On Fri, 28 Feb 2003, Gary Byers wrote:
>
> Hopefully, this is something mundane and easily fixed (and ideally the
> nregex problem and the paserve problem are the same.)
>

Well, it's certainly mundane.

Constant bitvectors aren't read correctly from fasl files, because
the function that tries to compute their size in 8-bit bytes does
so incorrectly.  0.13 shares this bug (and for all I know, commercial
MCL does as well.)

The function CCL::SUBTAG-BYTES takes an array typecode and an element
count and tries to calculate the (ceiling of the) number of 8-bit
bytes needed to hold element-count elements of the indicated array
type.  It uses the array typecode to determine the number of bits
per element (actually, the amount by which the element-count needs
to be shifted to yield the bit count), and mistakenly claims (in the
last clause of the big IF) that the number of bits in a bit vector
needs to be shifted left by 1 to yield the number of bits in a bit
vector.  (What is wrong with this picture ?).

Both COMPILE-FILE and the fasloader get this wrong consistently (both
call CCL:SUBTAG-BYTES), so COMPILE-FILE writes too many bytes to the
fasl file (padding the bitvector representation in the fasl file with
whatever was laying nearby in memory).  The fasloader will then create
a bitvector of the correct size, and tries to initialize it by reading
roughly twice as many bits as will fit.  In 0.13, objects are
allocated in strictly ascending memory-address order, so this will
usually cause random bits to be written past the free pointer.  That's
not good, but it's often harmless in practice.  (It'd certainly be
harmful if another thread allocated something between the time that
the fasloader allocated the bitvector and the time it tried to
initialize it.)

In 0.14, consing happens on a per-thread basis, and the per-thread
allocation pointer moves from high addresses to low.  Writing past
the end of an object like this is prety much guaranteed to clobber
some recently allocated object; in the case of nregex.dfsl, the
machine code of the function REGEX-QUOTED was getting overwritten
with random bits (hence the unhandled "illegal instruction" exception.)

The fix is in CVS.  With it in effect:

? (compile-file "nregex.lisp" :load t)  ; compile with fixed SUBTAG-BYTES

doesn't scribble over memory, and calling NREGEX:REGEX-COMPILE returns
a lambda expression.

(Since SUBTAG-BYTES is defined in level-0, you need to rebuild ppc-boot
and then rebuild an image for the fix to take effect.)





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