Martin Cracauer wrote:
Well, yes. However, in this case we are in a loop which contains
purely readonly code and the data in that hashtable becomes corrupted
from one iteration to the next, without ever leaving the loop. Except
for the GC, if the GC runs we get the corruption.
FWIW, there was a memory corruption problem in matlisp. A few
iterations of some loop would work ok, and maybe even a few GCs would be
ok, but eventually cmucl would die with a segfault (or something).
Eventually, the user isolated the problem to one routine and we figured
it out. A foreign routine was scribbling past the end of a Lisp array
because the Lisp array was only half the required size.
So I am not creating the damaged data myself, it is the GC not
realizing that this area of memory is in use by my program and
overwriting the location I point to with other stuff.
I am betting that the hash table is already corrupted in some way by the
time you get to your test code. You've obviously initialized the hash
tables by the time your code runs, so the damage could have occurred
then. Somewhat like what happens in C when you corrupt the stack or
heap. The error might not show up until much later in the program.
I don't envy you and the task ahead. :-(
Ray
