All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>
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	[thread overview]
Message-ID: <87h98a3wyd.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <e348f130-f1c7-456b-48cb-6734cf2a6762@redhat.com> (Paolo Bonzini's message of "Mon, 17 Oct 2016 23:08:16 +0200")

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.

>> 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	other threads:[~2016-10-18  8:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17 18:37 [Qemu-devel] qemu master tests/vmstate prints "Failed to load simple/primitive:b_1" etc Peter Maydell
2016-10-17 18:51 ` Dr. David Alan Gilbert
2016-10-17 19:04   ` Peter Maydell
2016-10-17 19:15     ` Dr. David Alan Gilbert
2016-10-17 21:08       ` Paolo Bonzini
2016-10-18  8:03         ` Markus Armbruster [this message]
2016-10-18  9:54           ` Dr. David Alan Gilbert
2016-10-18 13:38             ` Paolo Bonzini
2016-10-20 10:41               ` Dr. David Alan Gilbert
2016-10-24 14:26                 ` Paolo Bonzini
2016-10-20  8:41           ` Halil Pasic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h98a3wyd.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.