Re: [Qemu-devel] Valgrind confused by queue macros

[Andrey Shinkevich]

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