From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [kvm-unit-tests PATCH 3/6] arch-run: reduce return code ambiguity Date: Tue, 26 Jan 2016 22:31:56 +0100 Message-ID: <20160126213155.GA1844@potion.brq.redhat.com> References: <1453833731-23215-1-git-send-email-drjones@redhat.com> <1453833731-23215-4-git-send-email-drjones@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, pbonzini@redhat.com To: Andrew Jones Return-path: Received: from mx1.redhat.com ([209.132.183.28]:44040 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751321AbcAZVb7 (ORCPT ); Tue, 26 Jan 2016 16:31:59 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 659ACC049D4F for ; Tue, 26 Jan 2016 21:31:59 +0000 (UTC) Content-Disposition: inline In-Reply-To: <1453833731-23215-4-git-send-email-drjones@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 2016-01-26 19:42+0100, Andrew Jones: > qemu/unittest exit codes are convoluted, causing codes 0 and 1 > to be ambiguous. Here are the possible meanings > > .-----------------------------------------------------------------. > | | 0 | 1 | > |-----------------------------------------------------------------| > | QEMU | did something successfully, | FAILURE | > | | but probably didn't run the | | > | | unittest, OR caught SIGINT, | | > | | SIGHUP, or SIGTERM | | > |-----------------------------------------------------------------| > | unittest | for some reason exited using | SUCCESS | > | | ACPI/PSCI, not with debug-exit | | > .-----------------------------------------------------------------. > > As we can see above, an exit code of zero is even ambiguous for each > row, i.e. QEMU could exit with zero because it successfully completed, > or because it caught a signal. unittest could exit with zero because > it successfully powered-off, or because for some odd reason it powered- > off instead of calling debug-exit. > > And, the most fun is that exit-code == 1 means QEMU failed, but the > unittest succeeded. > > This patch attempts to reduce that ambiguity, by also looking at stderr. > > Signed-off-by: Andrew Jones > --- > diff --git a/scripts/arch-run.bash b/scripts/arch-run.bash > @@ -0,0 +1,62 @@ > +############################################################################## > +# exit_fixup translates the ambiguous exit status in Table1 to that in Table2. > +# Table3 simply documents the complete status table. > +# > +# Table1: Before fixup > +# -------------------- > +# 0 - Unexpected exit from QEMU (possible signal), or the unittest did > +# not use debug-exit > +# 1 - most likely unittest succeeded, or QEMU failed > +# > +# Table2: After fixup > +# ------------------- > +# 0 - Everything succeeded > +# 1 - most likely QEMU failed > +# > +# Table3: Complete table > +# ---------------------- > +# 0 - SUCCESS > +# 1 - most likely QEMU failed > +# 2 - most likely a run script failed > +# 3 - most likely the unittest failed > +# 127 - most likely the unittest called abort() > +# 1..127 - FAILURE (could be QEMU, a run script, or the unittest) > +# >= 128 - Signal (signum = status - 128) > +############################################################################## > +exit_fixup () > +{ > + local stdout errors nr_errors ret sig > + > + exec {stdout}>&1 > + mapfile -t errors < <("${@}" 2>&1 1>&${stdout}; echo $?) > + exec {stdout}>&- > + > + nr_errors=$((${#errors[@]} - 1)) > + ret=${errors[$nr_errors]} > + unset errors[$nr_errors] I think would be easier to understand as errors=$("${@}" 2>&1 1>&${stdout}) ret=$? # using [ "$errors" ] instead of [ $nr_errors -ne 0 ] > + > + if [ $nr_errors -ne 0 ]; then > + printf "%s\n" "${errors[@]}" Should go to stderr. (This reorders the output, so it would be a better to duplicate it when storing and print right away, but I only see inhumane designs for that.) > + sig=$(sed 's/.*terminating on signal \([0-9][0-9]*\).*/\1/' <<<"${errors[@]}") If ${errors[@]} don't contain just 'terminating [...]' and QEMU returned 0, some text will be assigned to sig, which isn't going to be handled well later on. > + fi > + > + if [ $ret -eq 0 ]; then > + # Some signals result in a zero return status, but the > + # error log tells the truth. > + if [ "$sig" ]; then > + ((ret=sig+128)) > + else > + # Exiting with zero (non-debugexit) is an error > + ret=1 > + fi > + elif [ $ret -eq 1 ]; then > + # Even when ret==1 (unittest success) if we also got stderr > + # logs, then we assume a QEMU failure. Otherwise we translate > + # status of 1 to 0 (SUCCESS) > + if [ $nr_errors -eq 0 ]; then > + ret=0 > + fi > + fi > + > + return $ret > +}