qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Valgrind confused by queue macros


From: Mark Syms
Subject: [Qemu-devel] Valgrind confused by queue macros
Date: Tue, 10 Sep 2019 13:27:08 +0000

Hi,

While trying to track down an issue in using qemu 4.1 with some development 
features we needed/wanted to run valgrind on it to find a memory error. 
Unfortunately the form of the queue macros seems to really confuse valgrind and 
cause it to report many " Use of uninitialised value " errors.

As an example, in qemu_aio_coroutine_enter - 

Use of uninitialised value of size 8
   at 0x69E7E5: qemu_aio_coroutine_enter (qemu-coroutine.c:109)

Conditional jump or move depends on uninitialised value(s)
   at 0x69E7FA: qemu_aio_coroutine_enter (qemu-coroutine.c:112)

Use of uninitialised value of size 8
   at 0x69E800: qemu_aio_coroutine_enter (qemu-coroutine.c:118)

Use of uninitialised value of size 8
   at 0x69E809: qemu_aio_coroutine_enter (qemu-coroutine.c:120)

Use of uninitialised value of size 8
   at 0x69E822: qemu_aio_coroutine_enter (qemu-coroutine.c:122)

Use of uninitialised value of size 8
   at 0x69E83A: qemu_aio_coroutine_enter (qemu-coroutine.c:134)

Use of uninitialised value of size 8
   at 0x69E845: qemu_aio_coroutine_enter (qemu-coroutine.c:139)

This seems to ultimately result from it thinking that pending is not 
initialised by this line

    QSIMPLEQ_HEAD(, Coroutine) pending = QSIMPLEQ_HEAD_INITIALIZER(pending);

As this issue in itself accounts for 7 errors every time that 
qemu_aio_coroutine_enter is called (which is frequently) valgrind very soon 
gives up and says the code is too broken to report errors on - unless that is 
you disable the error-limit which is what we've done but then you still have to 
identify the real errors in the middle of these ones.

Not sure what it is about the macros in the initialisation line that cause 
valgrind to think it isn't initialised, whilst there is a small amount of macro 
magic in there it looks like it does actually result in things being correctly 
initialised.

This is using valgrind 3.13.0-13.el7 on a CentOS 7 system.

Any clues about how to resolve this? Or is it just a fact of life that valgrind 
is never going to be happy with this code?

Thanks,

Mark.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]