[Python-Dev] valgrind

["Martin v. Löwis"]

Neal Norwitz schrieb:
>   at 0x44FA06: Py_ADDRESS_IN_RANGE (obmalloc.c:1741)
> 
> Note that the free is inside qsort.  The memory freed under qsort
> should definitely not be the bases which we allocated under
> PyType_Ready.  I'll file a bug report with valgrind to help determine
> if this is a problem in Python or valgrind.
> http://bugs.kde.org/show_bug.cgi?id=136989

As Tim explains, a read from Py_ADDRESS_IN_RANGE is fine, and by design.
If p is the pointer, we do

 pool = ((poolp)((Py_uintptr_t)(p) & ~(Py_uintptr_t)((4 * 1024) - 1)));

i.e. round down p to the start of the page, to obtain "pool". Then we
do

 f (((pool)->arenaindex < maxarenas && (Py_uintptr_t)(p) -
arenas[(pool)->arenaindex].address < (Py_uintptr_t)(256 << 10) &&
arenas[(pool)->arenaindex].address != 0))

i.e. access pool->arenaindex. If this is our own memory, we really find
a valid arena index there. If this is malloc'ed memory, we read garbage
- due to the page size, we are guaranteed to read successfully, still.
To determine whether it's garbage, we look it up in the arenas array.

> One other thing that is weird is that the complaint is about 4 bytes
> which should not be possible.  All pointers should be 8 bytes AFAIK
> since this is amd64.

That's because the arenaindex is unsigned int. We could widen it to
size_t, if we don't, PyMalloc can "only" manage 1 PiB (with an
arena being 256kiB, and 4Gi arena indices being available).

> I also ran this on x86.  There were 32 errors and all of their
> addresses were 0x4...010.

That's because we round down to the beginning of the page.

Regards,
Martin