[Bug-openmcl] problem compiling maxima

[Gary Byers]

On Wed, 10 Dec 2003, Timothy Moore wrote:

>
> On Dec 10, 2003, at 12:30 AM, Gary Byers wrote:
> >>> Just to be sure that I understand: does it seem to be the case that
> >>> (somehow or other, in the environment in which maxima's being
> >>> compiled)
> >>> things are somehow hosed to the point where this fails mysteriously,
> >>> even though in isolation it looks like a pretty simple macro ?
> >
> >> Yes, exactly. The macro works for me to in isolation, but after
> >> compiling around 30 files something seems to be corrupted.
> >

It turns out that there were two bugs, and things indeed got badly
corrupted:

  1) if the per-thread special-binding table wasn't big enough, a
     trap handler in the lisp kernel used the realloc() function
     to make it bigger (OK), then called free() on the old table
     address (very much NOT ok, for a number of reasons ...).
  2) to add insult to injury, the assembly-language code was holding
     on to a pointer to the old binding table (the one that had just
     been erroneously doubly-freed.)  Bad enough that it's not saving
     the binding info where subsequent references will find them,
     but scribbling over doubly-freed memory -can't- be a good thing.

I'm still a little suspicious that maxima may not -want- all of those
sometimes-special variables, and something makes me thing that that's
happening accidentally, though the binding primitives should obviously
scale up to handle programs that really -do- want to bind/reference
an arbitrary number of special variables.

After fixing these bugs and rebuilding the lisp kernel, I was able
to build a maxima image.  The fixes are in CVS (in the main 0.14 tree).