[Python-Dev] valgrind

["Martin v. Löwis"]

Herman Geza schrieb:
>> 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?

It can't, as the hardware won't support it.

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

It can't. In brk, you can only manage memory in chunks of "one page"
(i.e. 4kiB on x86). Since we only access memory on the same page,
access is guaranteed to succeed.

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

Likewise. This is guaranteed to work, by the processor manufacturers.

> I don't really think that reading from an already-freed block is ever 
> legal. 

Define "legal". There is no law against it; you don't go to jail for
doing it. What other penalties would you expect (other than valgrind
spitting out error messages, and users complaining from time to time
that it's "illegal")?

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

If it is this case, then no, valgrind is right. Notice that valgrind
doesn't call them "illegal"; it calls them "invalid".

> I just want to be sure that I'll never get SIGSEGV from python.

You least won't get SIGSEGVs from that part of the code.

> Note that Misc/valgrind-python.supp contains suppressions "Invalid read"'s 
> at Py_ADDRESS_IN_RANGE.

Right. This is to tell valgrind that these reads are known to work
as designed.

Regards,
Martin