I'm getting
*** glibc detected *** (/my/program/...): malloc(): memory corruption: 0xf28000fa ***
I've run under valgrind, which reports cases of reading memory that has been freed, but no cases of illegal memory writes.
Could reading freed memory cause memory corruption? If not, any suggestions where else to look beyond the valgrind output?
It won't corrupt the memory you read, but it isn't going to do wonders for the working of your program.
You can use GDB to watch each write in this memory address, like this:
(gdb) watch *((int*)0xf28000fa)
Then you can debug where the problem is.
Reading doesn't cause memory corruption, but there are a lot of situations that you don't even imagine that could be the cause of this, and Valgrind is not a perfect tool.
See more information about debugging memory issues here.
Reading freed memory is also considered memory corruption.
You can also check http://en.wikipedia.org/wiki/Memory_corruption.
No, reading invalid locations can't possibly cause the error you are seeing. If the location is valid in your address space, you'll just be reading junk, if not, you'll get a segmentation fault.
Check valgrind's output to see where the invalid reads are coming from - this will give you a hint towards where the real mistake lies. Once you find this, I'm quite sure the real culprit won't be far away, and it's probably an invalid write.
It shouldn't be that common on current processors, but I've worked on platforms where even a read operation could do magic. In the specific 6502 processor has mapped I/O, so a regular "read" instruction with a I/O mapped address can do surprising stuff.
About 30 years ago I got bitten by that because my bad read provoked a memory bank switch (that is every byte of memory, including the area containing the code, got a new different value just after that instruction). The funny part is that it wasn't a truly "unintentional" bad read... I actually did the read even if knowing that it was going to be garbage because this saved me a few assembler instructions... not a smart move.
What can really happen, is that free can use madvise(MADV_DONTNEED) syscall to tell the kernel "I don't need this page, drop it" (see madvise(2) manpage). If that page gets really deallocated and you read anything from it, kernel will silently provide freshly new page, zeroed out - and thus cause your application to encounter completely unexpected data!