Re: Seeing memory corruption, GC moves my objects around

Martin Cracauer <cracauer@xxxxxxxx> writes:

> None of the new features, including none of your fancier PCL work are
> in.

That's some good news :).

> > I've quite often managed to get there by using (SETF %INSTANCE-REF) or
> > SVREF or similar things with invalid indices in SAFETY 0 code, thereby
> > overwriting random stuff beyond an instance or vector or whatever.
> 
> 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.
> 
> 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.

Hm.  I don't see at present how a hash-table could be live (=
scavenged), without all its entries being scavenged, too.  One pretty
much implies the other.  And that GC later overwrites an already
copied object feels unlikely, judging from the code I've seen in
gencgc.c.

Maybe you could try to activate the debug output in scav_hash_vector,
possibly with setting a C variable from Lisp that activates the trace
output only in the relevant section of code?

> That is what puzzles me - I had plenty of overwritten memory by direct
> action of my code, but I never managed to trick the GC into assuming a
> memory area is unused when it wasn't.
> 
> > >    If we promised something to be a fixnum and put a pointer-containing
> > >    object in it I assume we could do that.
> > 
> > If "it" is a structure slot with no type declaration as you say, yes.
> 
> Can you elaborate a little? Why do you say the slot wouldn't have to
> have a type declaration?

Sorry, I didn't want to complicate matters, and now I've done it.

If the slot had a type declaration, it could have been, depending on
the type, be a "raw" slot, which are used for unboxed values (see
ALLOCATE-1-SLOT in defstruct.lisp).  Instances with raw slots store
values of these slots in a (UNSIGNED-BYTE 32) array, IIRC.  Storing a
reference to a non-immediate Lisp object in such a slot when no other
references to it remain should be dangerous, for example.  Dunno what
other consequences type mismatches can have with raw slots.

> I was rather thinking that violating an existing declaration would
> cause this trouble.

For non-raw slots, setting a slot is a (SETF INSTANCE-REF) with the
index of the slot, which I think should always be valid, plus a normal
type check.  Storing any boxed object in such a slot cannot possibly
confuse GC, even if the type check is not done for some reason.
Storing something unboxed could of course a problem, if that is
possible, dunno, because GC will expect something boxed there.