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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
