"Martin v. Löwis"
martin at v.loewis.de
Tue Nov 7 15:31:18 CET 2006
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.
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
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.
More information about the Python-Dev