From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bx8vD-0003gG-G9 for qemu-devel@nongnu.org; Thu, 20 Oct 2016 04:42:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bx8v9-0002VQ-JF for qemu-devel@nongnu.org; Thu, 20 Oct 2016 04:41:55 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:57633) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bx8v9-0002Up-BM for qemu-devel@nongnu.org; Thu, 20 Oct 2016 04:41:51 -0400 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9K8ckFC016577 for ; Thu, 20 Oct 2016 04:41:50 -0400 Received: from e06smtp06.uk.ibm.com (e06smtp06.uk.ibm.com [195.75.94.102]) by mx0a-001b2d01.pphosted.com with ESMTP id 266suyab33-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Oct 2016 04:41:49 -0400 Received: from localhost by e06smtp06.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 20 Oct 2016 09:41:47 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 2AC4E1B08061 for ; Thu, 20 Oct 2016 09:43:49 +0100 (BST) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u9K8fjsQ13893816 for ; Thu, 20 Oct 2016 08:41:45 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u9K7fkn2025956 for ; Thu, 20 Oct 2016 01:41:46 -0600 References: <20161017185126.GD12934@work-vm> <20161017191550.GG12934@work-vm> <87h98a3wyd.fsf@dusky.pond.sub.org> From: Halil Pasic Date: Thu, 20 Oct 2016 10:41:44 +0200 MIME-Version: 1.0 In-Reply-To: <87h98a3wyd.fsf@dusky.pond.sub.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Message-Id: 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: Markus Armbruster , Paolo Bonzini Cc: Peter Maydell , "Dr. David Alan Gilbert" , QEMU Developers On 10/18/2016 10:03 AM, Markus Armbruster wrote: > 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. > +1 For this particular case, I think it is viable too. Halil