问题
So given this output:
==80518== Invalid read of size 4
==80518== at 0x558D: Node::ReadFolder(GFile*) (in ./ScribeRecoverMail2)
==80518== by 0x7B61: Worker::Export(GFile*, GArray<Node*>&) (in ./ScribeRecoverMail2)
==80518== by 0x8F7A: Worker::Main() (in ./ScribeRecoverMail2)
==80518== by 0x142D64: ThreadEntryPoint(void*) (in /Users/matthew/Code/Scribe-Branches/v2.00/Utils/ScribeRecoverMail2/build/Debug/ScribeRecoverMail2.app/Contents/Frameworks/Lgi.framework/Versions/A/Lgi)
==80518== by 0x47E258: _pthread_start (in /usr/lib/libSystem.B.dylib)
==80518== by 0x47E0DD: thread_start (in /usr/lib/libSystem.B.dylib)
==80518== Address 0x1d72f590 is 16 bytes inside a block of size 72 alloc'd
==80518== at 0x41581: malloc (vg_replace_malloc.c:266)
==80518== by 0x3D5616: operator new(unsigned long) (in /usr/lib/libstdc++.6.0.9.dylib)
==80518== by 0x77A6: Worker::Scan(GFile*, GArray<Node*>&) (in ./ScribeRecoverMail2)
==80518== by 0x8F0C: Worker::Main() (in ./ScribeRecoverMail2)
==80518== by 0x142D64: ThreadEntryPoint(void*) (in /Users/matthew/Code/Scribe-Branches/v2.00/Utils/ScribeRecoverMail2/build/Debug/ScribeRecoverMail2.app/Contents/Frameworks/Lgi.framework/Versions/A/Lgi)
==80518== by 0x47E258: _pthread_start (in /usr/lib/libSystem.B.dylib)
==80518== by 0x47E0DD: thread_start (in /usr/lib/libSystem.B.dylib)
==80518==
==80518== Invalid read of size 4
==80518== at 0x10B70F: GFile::Read(void*, int, int) (in /Users/matthew/Code/Scribe-Branches/v2.00/Utils/ScribeRecoverMail2/build/Debug/ScribeRecoverMail2.app/Contents/Frameworks/Lgi.framework/Versions/A/Lgi)
==80518== by 0x360E: Node::Read(GFile*, unsigned int&) (in ./ScribeRecoverMail2)
==80518== by 0x55CF: Node::ReadFolder(GFile*) (in ./ScribeRecoverMail2)
==80518== by 0x7B61: Worker::Export(GFile*, GArray<Node*>&) (in ./ScribeRecoverMail2)
==80518== by 0x8F7A: Worker::Main() (in ./ScribeRecoverMail2)
==80518== by 0x142D64: ThreadEntryPoint(void*) (in /Users/matthew/Code/Scribe-Branches/v2.00/Utils/ScribeRecoverMail2/build/Debug/ScribeRecoverMail2.app/Contents/Frameworks/Lgi.framework/Versions/A/Lgi)
==80518== by 0x47E258: _pthread_start (in /usr/lib/libSystem.B.dylib)
==80518== by 0x47E0DD: thread_start (in /usr/lib/libSystem.B.dylib)
==80518== Address 0x1a198900 is 0 bytes inside a block of size 24 alloc'd
==80518== at 0x41581: malloc (vg_replace_malloc.c:266)
==80518== by 0x3D5616: operator new(unsigned long) (in /usr/lib/libstdc++.6.0.9.dylib)
==80518== by 0xDFADB: GFile::GFile() (in /Users/matthew/Code/Scribe-Branches/v2.00/Utils/ScribeRecoverMail2/build/Debug/ScribeRecoverMail2.app/Contents/Frameworks/Lgi.framework/Versions/A/Lgi)
==80518== by 0x8E4E: Worker::Main() (in ./ScribeRecoverMail2)
==80518== by 0x142D64: ThreadEntryPoint(void*) (in /Users/matthew/Code/Scribe-Branches/v2.00/Utils/ScribeRecoverMail2/build/Debug/ScribeRecoverMail2.app/Contents/Frameworks/Lgi.framework/Versions/A/Lgi)
==80518== by 0x47E258: _pthread_start (in /usr/lib/libSystem.B.dylib)
==80518== by 0x47E0DD: thread_start (in /usr/lib/libSystem.B.dylib)
It seems that Valgrind is complaining about normal everyday behaviour. The blocks in question are still allocated, and the access is inside the memory blocks start and end. So why does valgrind complain?
This program does crash on windows, so I built it on Mac to valgrind it and see where things are going wrong. So far lots of these "error inside block" warnings but nothing dubious like "write to free'd memory" or anything. I'm quite confused.
PS running latest stable valgrind v3.7.0, compiled and install on the same machine as I'm running it. I have been using valgrind for a long time, and never seen this sort of message before.
回答1:
It seems that Valgrind is complaining about normal everyday behaviour
Indeed it does, and that appears to be a bug in Mac OSX version of Valgrind.
You can try to create a small test case and report it to Valgrind developers.
You could also try address sanitizer and see what it reports.
来源：https://stackoverflow.com/questions/10159293/why-is-valgrind-reporting-read-write-errors-inside-valid-blocks