Re: [Qemu-devel] [PATCH v5 05/46] qapi: Test use of 'number' within alternates

[Eric Blake]

On 09/24/2015 10:29 AM, Markus Armbruster wrote:

>>> Any particular reason for adding the initializer?
>>>
>>>>
>>>>      v = visitor_input_test_init(data, "42");
>>>>
>>>> -    visit_type_UserDefAlternate(v, &tmp, NULL, &err);
>>>> -    g_assert(err == NULL);
>>>> +    visit_type_UserDefAlternate(v, &tmp, NULL, &error_abort);
>>
>> Hmm - I don't know if we have a clear contract for what happens if you
>> call visit_type_FOO on an uninitialized pointer.  It may have been
>> succeeding by mere luck.
> 
> I strongly suspect the "input" visitors are assignment-like: they store
> something, and don't care what value they overwrite.  Let's keep that in
> mind when we retrofit a contract.
> 

Hmm. When I delete the initializer, valgrind starts warning at a later
point in my series:

/visitor/input/errors: OK
/visitor/input/alternate-number: ==16451== Conditional jump or move
depends on uninitialised value(s)
==16451==    at 0x14AA7E: visit_start_implicit_struct (qapi-visit-core.c:36)
==16451==    by 0x111D80: visit_type_AltStrBool (test-qapi-visit.c:207)
==16451==    by 0x10EC16: test_visitor_in_alternate_number
(test-qmp-input-visitor.c:426)
==16451==    by 0x4EBBB92: test_case_run (gtestutils.c:2124)
==16451==    by 0x4EBBB92: g_test_run_suite_internal (gtestutils.c:2185)
==16451==    by 0x4EBBD5A: g_test_run_suite_internal (gtestutils.c:2196)
==16451==    by 0x4EBBD5A: g_test_run_suite_internal (gtestutils.c:2196)
==16451==    by 0x4EBC0DA: g_test_run_suite (gtestutils.c:2249)
==16451==    by 0x4EBC110: g_test_run (gtestutils.c:1553)
==16451==    by 0x111406: main (test-qmp-input-visitor.c:901)
==16451==  Uninitialised value was created by a stack allocation
==16451==    at 0x10EBA1: test_visitor_in_alternate_number
(test-qmp-input-visitor.c:413)

I don't know if that means my changes are introducing the problems, or
if we really DO want to require users to pass in an initial NULL
pointer. I've run out of time to investigate today, but it's not turning
out to be as trivial as I had hoped.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature