Re: Seeing memory corruption, GC moves my objects around

Martin Cracauer <cracauer@xxxxxxxx> writes:

> I am on late CMUCL 18 on x86-linux.  I have all memory spaces moved
> and resized but I am otherwise not noticeably different from stock
> CMUCL 18.

How does your CMUCL relate to CVS CMUCL or CMUCL releases?

In other words, which new suspects/features are present?
(Dynamic-extent and weak hash table support in gencgc coming to mind,
in particular.)

> So my questions for debugging strategies are:
> 
> 1) assume we have wrong type declarations.  What would be a scenario
>    where we promise to be of one type, put in another and confuse the
>    GC?

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.

>    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.

> 2) is there maybe a problem with hashtables and GC, maybe with
>    hashtables in special variables? Anybody ever found such a
>    problem?

Not me.

> Generally, any suggestions what I can do to figure out what is going
> on here?

In the cases I encountered, compiling with SAFETY 3 caught the error
I was making.

(If it happens with one particular kernel version only, there is of
course also the possibility that the bug is something completely
different, maybe a kernel bug, configuration bug (libc + kernel), or
even a hardware defect that a changed VM system exposes.  Slightly
mismatching libc + kernel on GNU/Linux were my personal favourites
while maintaining Emacs ("oh yes, now that you mention it, I really
forgot to tell that Emacs started to crash after I installed/upgraded
...".  @!$%$%!!)