On Tue, 7 Nov 2006, Tim Peters wrote:
When PyObject_Free is handed an address it doesn't control, the "arena base address" it derives from that address may point at anything the system malloc controls, including uninitialized memory, memory the system malloc has allocated to something, memory the system malloc has freed, or internal system malloc bookkeeping bytes. The Py_ADDRESS_IN_RANGE macro has no way to know before reading it up.
So figure out which line of code valgrind is complaining about (doesn't valgrind usually produce that?). If it's coming from the expansion of Py_ADDRESS_IN_RANGE, it's not worth more thought. Hmm. I don't think that way. What if free() does other things? For example if free(addr) sees that the memory block at addr is the last block then it may call brk with a decreased end_data_segment. Or the last block in an mmap'd area - it calls unmap. So when Py_ADDRESS_IN_RANGE tries to read from this freed memory block it gets SIGSEGV. However, I've never got SIGSEGV from python.
I don't really think that reading from an already-freed block is ever legal. I asked my original question because I saw that I'm not the only one who sees "Illegal reads" from python. Is valgrind wrong in this case? I just want to be sure that I'll never get SIGSEGV from python. Note that Misc/valgrind-python.supp contains suppressions "Invalid read"'s at Py_ADDRESS_IN_RANGE. Geza Herman