On Mon, 06/12 17:20, John Snow wrote: > I noticed while debugging an unrelated test that our use of the null > driver has a habit of making functions like find_image_format trigger a > lot of uninitialized memory errors in valgrind, because it will return a > successful read without actually touching the buffer. > > I see that in March there was a bit of a debate over whether or not the > null driver SHOULD zero-write memory for performance reasons, but when > this option isn't specified, the semantics of read are arguably broken. > > This isn't terribly important to fix, but for actual debugging purposes > it's nice to not have valgrind screaming at you with spurious junk. A > few options: > > (1) Admit that it's weird to allow reads to succeed with null-co driver. > Annoy people who apparently wanted performance for their do-nothing > driver and force the initialization of memory. > > --or-- > > (1a) Use valgrind macros to pretend the memory has been initialized.
I assume this macro be used in find_image_format? Not great. > > (2) Band-aid find_image_format to zero-initialize memory. Wonder if > there are other usages of read() getting called from tests that utilize > null-co that will make debugging difficult in other contexts. I don't think there are many places in QEMU code where the buffer returned by null-co is inspected, so this may be feasible. Test code that read the buffer should already initialize the buffer, or use zero option. > > (3) Edit any tests to always use the zero option when using the null > driver, and then periodically keep updating this option in a losing > battle over time. > > (4) Find a way to adjust return value of null-co's read implementation > to return 0 instead of a lie over the number of bytes it read/wrote. > Correctly represents "No bytes written, but no error occurred either." This is going to break a lot of things, I'm afraid. Another option is making null always zero the first sectors. Fam