On 12/09/2019 02:15, John Snow wrote: > > > On 9/10/19 9:27 AM, Mark Syms wrote: >> 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. >> > > I haven't used valgrind on a "real" run of QEMU in some time, usually > using it for the test suite instead. > > In this case, are you sure it's choking on the macro and not getting > confused about all of the stack swaps that QEMU is doing in the > coroutine module? > > CCing some folks who have worked on valgrind support in the past, they > might have a more targeted idea. > > --js >
The 'gcc -E util/qemu-coroutine.c' shows the explicit initialization as this: void qemu_aio_coroutine_enter(AioContext *ctx, Coroutine *co) { struct { struct Coroutine *sqh_first; struct Coroutine **sqh_last; } pending = { ((void *)0), &(pending).sqh_first }; ... Please send the command you ran the Valgrind with to see the options. If you can reproduce the case running the Valgrind with the options 'track-origins=yes' and '--log-file=name.log', the resulting log files will be helpful. Thanks, Andrey -- With the best regards, Andrey Shinkevich