Re: [Qemu-devel] qemu master tests/vmstate prints "Failed to load simple/primitive:b_1" etc

[Halil Pasic <pasic@linux.vnet.ibm.com>]

On 10/18/2016 10:03 AM, Markus Armbruster wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>> > On 17/10/2016 21:15, Dr. David Alan Gilbert wrote:
>>> >> * Peter Maydell (peter.maydell@linaro.org) wrote:
>>>> >>> On 17 October 2016 at 19:51, Dr. David Alan Gilbert <dgilbert@redhat.com> wrote:
>>>>> >>>> * Peter Maydell (peter.maydell@linaro.org) wrote:
>>>>>> >>>>> I've just noticed that qemu master running 'make check' prints
>>>>>> >>>>>   GTESTER tests/test-vmstate
>>>>>> >>>>> Failed to load simple/primitive:b_1
>>>>>> >>>>> Failed to load simple/primitive:i64_2
>>>>>> >>>>> Failed to load simple/primitive:i32_1
>>>>>> >>>>> Failed to load simple/primitive:i32_1
>>>>>> >>>>>
>>>>>> >>>>> but the test doesn't fail.
>>>>>> >>>>>
>>>>>> >>>>> Can we either (a) silence this output if it's spurious or (b) have
>>>>>> >>>>> it cause the test to fail if it's real (and fix the cause of the
>>>>>> >>>>> failure ;-)), please?
>>>>> >>>>
>>>>> >>>> The test (has always) tried loading truncated versions of the migration
>>>>> >>>> stream and made sure that it receives an error from vmstate_load_state.
>>>>> >>>>
>>>>> >>>> However I just added an error so we can see which field fails to load
>>>>> >>>> in a migration where we just used to get a 'migration has failed with -22'
>>>>> >>>>
>>>>> >>>> Is there a way to silence error_report's that's already in use in tests?
>>>> >>>
>>>> >>> We have some nasty hacks (like check for 'qtest_enabled()' before
>>>> >>> calling error_report()) but we don't have anything in the
>>>> >>> tree today that's a more coherent approach to the "test
>>>> >>> deliberately provoked this error" problem.
> I guess the "more coherent approach" would be some way to run a piece of
> code with error reporting suppressed.
> 
> For unit tests, a need to supress error reporting indicates the code
> under test should perhaps error_setg() instead of error_report().
> Unlikely to completely eliminate the need to suppress error reporting,
> though.
> 
+1

For this particular case, I think it is viable too.

Halil