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 _______________________________________________ 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
