[Bug-openmcl] problem compiling maxima
gb at clozure.com
Wed Dec 10 00:13:12 MST 2003
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
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).
More information about the Bug-openmcl