|
From: Patrick J. L. <lop...@gm...> - 2012-02-18 20:40:46
|
So I have decided to take a crack at fixing the bug I reported (https://bugs.kde.org/show_bug.cgi?id=294285). After reading the memcheck code a bit, I think I have some idea how to proceed, but I am confused by the following function in mc_main.c: static INLINE Bool get_vbits8 ( Addr a, UChar* vbits8 ) { Bool ok = True; UChar vabits2 = get_vabits2(a); // Convert the in-memory format to in-register format. if ( VA_BITS2_DEFINED == vabits2 ) { *vbits8 = V_BITS8_DEFINED; } else if ( VA_BITS2_UNDEFINED == vabits2 ) { *vbits8 = V_BITS8_UNDEFINED; } else if ( VA_BITS2_NOACCESS == vabits2 ) { *vbits8 = V_BITS8_DEFINED; // Make V bits defined! ok = False; } else { tl_assert( VA_BITS2_PARTDEFINED == vabits2 ); *vbits8 = get_sec_vbits8(a); } return ok; } I see the comment "Make B bits defined!". My question is: Why? Why would you want to treat inaccessible memory as "defined"? One result of this is to make "--partial-loads-ok" behave incorrectly. The purpose of "--partial-loads-ok" is to avoid false positives for the (increasingly common) case of reading a whole aligned word from memory that happens to extend beyond the bounds of an allocated block. But this is only legal if the out-of-bounds data -- loaded by the whole-word aligned read -- are never used for anything. Since the NOACCESS bits are treated as defined, "--partial-loads-ok" not only lets you read those out-of-bounds bytes; it actually lets you _use_ them without an error, which is wrong. At least, I think it is wrong, and I have a simple test case demonstrating the problem. In summary, my questions are: 1) What is the rationale here? 2) Should I file this "--partial-loads-ok" behavior as a bug? - Pat |
|
From: Julian S. <js...@ac...> - 2012-02-18 22:28:25
|
> Since the NOACCESS bits are treated as defined, "--partial-loads-ok" > not only lets you read those out-of-bounds bytes; it actually lets you > _use_ them without an error, which is wrong. > > At least, I think it is wrong, and I have a simple test case > demonstrating the problem. > > In summary, my questions are: > > 1) What is the rationale here? See last part of Sec 2.7 of http://valgrind.org/docs/memcheck2005.pdf although that is subtly different; it discusses what to do about the V bits for mem accesses which are unambiguously out of bounds. J |