[Openmcl-devel] Another linux86-32: signed doubleword parameters.
lisp at davidb.org
Wed Oct 15 05:21:41 UTC 2008
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
- 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.
More information about the Openmcl-devel