[Qemu-devel] Valgrind confused by queue macros

[Qemu-devel] Valgrind confused by queue macros

[Mark Syms]

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.

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

[John Snow]

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

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