[Openmcl-devel] Another linux86-32: signed doubleword parameters.

[David Brown]

On Tue, Oct 14, 2008 at 09:41:17AM -0600, Gary Byers wrote:

> There are probably lots of scenarios that -can- lead to that sort of thing.
> One canonical example involves unsafe code storing outside the bounds
> of an object.  Suppose that memory contains

Ok, a few things that make me think this isn't a problem with unsafe
code:

   - The code works fine on ccl64, as well as sbcl.

   - I've wrapped every pointer in my code with some code that copies
     the block, puts a pattern around it, evaluates the body, checks
     the pattern, and it has never caught this.

   - I've also wrapped every with-pointer-to-ivector with something
     that takes the address as an integer, and compares it with the
     pointer again afterward, just to make sure the GC didn't move
     things around.  Never saw this, but wasn't really expecting to.

The only thing I haven't done is try running this code on another
32-bit system.  I'll need to build sbcl on the 32-bit machine to see
if I can figure out what this might show.

> The integrity checks usually catch this kind of memory corruption.
> If they're enabled and things were OK after the most recent GC,
> then ... well, the GC isn't totally exonerated, but it's a less
> likely suspect.   Those checks aren't perfect, but they do catch
> a lot of inconsistencies.

So, both kinds of integrity checks on, and nothing (gc, and my padded
buffer check).  The problem only happens with threading and only on
x86 ccl, not on x86_64 ccl64 nor SBCL on x86_64.

I'll also see if I can track down one of these bogus objects.  It's
kind of hard, since there doesn't seem to be a pattern.

David