qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] qemu master tests/vmstate prints "Failed to load simple/primitive:b_1" etc
Date: Tue, 18 Oct 2016 10:03:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Paolo Bonzini <address@hidden> writes:

> On 17/10/2016 21:15, Dr. David Alan Gilbert wrote:
>> * Peter Maydell (address@hidden) wrote:
>>> On 17 October 2016 at 19:51, Dr. David Alan Gilbert <address@hidden> wrote:
>>>> * Peter Maydell (address@hidden) 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.

>> Errors go to either the current monitor (if it's non-qmp) or
>> stderr; so could we create a dummy monitor to eat the errors
>> and make it current around that part?
>
> I guess you could reimplement the functions of stubs/mon-printf.c and
> stubs/mon-is-qmp.c.

qemu-error.c does all its output via error_vprintf():

    void error_vprintf(const char *fmt, va_list ap)
    {
        if (cur_mon && !monitor_cur_is_qmp()) {
            monitor_vprintf(cur_mon, fmt, ap);
        } else {
            vfprintf(stderr, fmt, ap);
        }
    }

Thus, custom monitor_cur_is_qmp() and monitor_vprintf() let you capture
its output.

Using (or rather abusing) this to suppress error reporting for an entire
program would be easy enough.  But I doubt it's a convenient way to
suppress more narrowly.

I figure a monitor connected to a "null" chardev would work better
there.  If we need that anyway, using it for the "entire program" case
as well is probably easiest.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]