From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwPNP-0007ar-2e for qemu-devel@nongnu.org; Tue, 18 Oct 2016 04:04:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwPNN-000819-VP for qemu-devel@nongnu.org; Tue, 18 Oct 2016 04:03:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56322) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwPNN-00080q-Nu for qemu-devel@nongnu.org; Tue, 18 Oct 2016 04:03:57 -0400 From: Markus Armbruster References: <20161017185126.GD12934@work-vm> <20161017191550.GG12934@work-vm> Date: Tue, 18 Oct 2016 10:03:54 +0200 In-Reply-To: (Paolo Bonzini's message of "Mon, 17 Oct 2016 23:08:16 +0200") Message-ID: <87h98a3wyd.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] qemu master tests/vmstate prints "Failed to load simple/primitive:b_1" etc List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "Dr. David Alan Gilbert" , Peter Maydell , QEMU Developers Paolo Bonzini 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 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.