QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
* [Qemu-devel] Valgrind confused by queue macros
@ 2019-09-10 13:27 Mark Syms
  2019-09-11 23:15 ` John Snow
  0 siblings, 1 reply; 3+ messages in thread
From: Mark Syms @ 2019-09-10 13:27 UTC (permalink / raw)
  To: qemu-devel

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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] Valgrind confused by queue macros
  2019-09-10 13:27 [Qemu-devel] Valgrind confused by queue macros Mark Syms
@ 2019-09-11 23:15 ` John Snow
  2019-09-12 13:35   ` Andrey Shinkevich
  0 siblings, 1 reply; 3+ messages in thread
From: John Snow @ 2019-09-11 23:15 UTC (permalink / raw)
  To: Mark Syms, qemu-devel; +Cc: Christian Borntraeger, Andrey Shinkevich



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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] Valgrind confused by queue macros
  2019-09-11 23:15 ` John Snow
@ 2019-09-12 13:35   ` Andrey Shinkevich
  0 siblings, 0 replies; 3+ messages in thread
From: Andrey Shinkevich @ 2019-09-12 13:35 UTC (permalink / raw)
  To: John Snow, Mark Syms, qemu-devel; +Cc: Christian Borntraeger, Denis Lunev



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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-10 13:27 [Qemu-devel] Valgrind confused by queue macros Mark Syms
2019-09-11 23:15 ` John Snow
2019-09-12 13:35   ` Andrey Shinkevich

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
		qemu-devel@nongnu.org qemu-devel@archiver.kernel.org
	public-inbox-index qemu-devel


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox