[pypy-dev] [pypy-commit] pypy default: investigate mark_opaque_ptr

[Hakan Ardo]

On Mon, Oct 13, 2014 at 6:09 PM, Armin Rigo <arigo at tunes.org> wrote:
>
> I think it should work.

I'm sure your right :)

> What I have in mind for GUARD_GCTYPE would be
> to check the GC header of the object; all GC pointers have one, with
> our own GCs --- even GcArrays.  So GUARD_GCTYPE would check that the
> object is exactly of the correct type: the right kind of GcArray, or
> the right kind of GcStruct that is not necessarily an RPython
> instance.  It would be inserted before we do more checks with that
> pointer, whenever the pointer may originally be opaque.

Are we certain opaque pointers always refer to GC-objects?

>
> Btw, a GUARD_CLASS on an opaque pointer that is not actually an
> RPython instance may also crash, depending on the translation
> settings.  I think it works without problem if "gcremovetypeptr" is
> True (the default on 64-bit, but not on 32-bit).  If it is False, then
> we have a very unlikely but possible false positive where the check is
> done by reading the 2nd word of the object, just after the GC header,
> and checking that it is exactly some value.  If the object is
> actually, say, a tuple of integers, then it would be possible that the
> first integer has exactly the same value as expected.  So unless I'm
> missing something else, we have a potential bug that involves creating
> a range(a, b, c) with a being exactly the same as the address of some
> vtable thing...

Right, but mark_opaque_ptr prevents this case as well by not moving
operations using opaque pointers into the short preamble. So I guess
we are currently fine?


-- 
Håkan Ardö