hg211 at hszk.bme.hu
Tue Nov 7 15:54:54 CET 2006
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
More information about the Python-Dev