[xen-4.3-testing test] 24332: regressions - FAIL

[xen-4.3-testing test] 24332: regressions - FAIL

[xen.org]

[-- Attachment #1: Type: text/plain, Size: 14041 bytes --]

flight 24332 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/24332/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-oldkern           4 xen-build        fail in 24322 REGR. vs. 22383

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore   fail pass in 24322
 test-armhf-armhf-xl           6 capture-logs(6)  broken in 24322 pass in 24332

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail like 24336-bisect

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-armhf-armhf-xl           5 xen-boot                     fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop    fail in 24322 never pass

version targeted for testing:
 xen                  6d7b67c67039ceac36a780b59c2b890739094b95
baseline version:
 xen                  8940a13d6de1295cfdc4a189e0a5610849a9ef59

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Julien Grall <julien.grall@linaro.org>
  Matthew Daley <mattd@bugfuzz.com>
  Roger Pau Monné <roger.pau@citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-amd64-i386-xl                                           pass    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-i386-freebsd10-amd64                              pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-i386-freebsd10-i386                               pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 6d7b67c67039ceac36a780b59c2b890739094b95
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Mon Nov 25 11:05:47 2013 +0000

    tools/xc_restore: Initialise console and store mfns
    
    If the console or store mfn chunks are not present in the migration stream,
    stack junk gets reported for the mfns.
    
    XenServer had a very hard to track down VM corruption issue caused by exactly
    this issue.  Xenconsoled would connect to a junk mfn and incremented the ring
    pointer if the junk happend to look like a valid gfn.
    
    Coverity ID: 1056093 1056094
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    CC: Ian Campbell <Ian.Campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 592b614f3469bb83d1158c3dc8c15b67aacfbf4f)

commit a859a20735421164b718136d6134b4385235d48e
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date:   Thu Jan 9 12:29:54 2014 +0000

    QEMU_TAG update

commit 0c815a0e5308aa5048e5c9959eeb9836917cf17e
Author: Julien Grall <julien.grall@linaro.org>
Date:   Thu Dec 19 16:45:03 2013 +0000

    tools/libx: xl uptime doesn't require argument
    
    The current behavior is:
    
    42sh> xl uptime
    'xl uptime' requires at least 1 argument.
    
    Usage: xl [-v] uptime [-s] [Domain]
    
    The normal behavior should list uptime for each domain when there is no
    parameters.
    
    Signed-off-by: Julien Grall <julien.grall@linaro.org>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 3533972f6d423e71533ffbce5cb9d84bd1a9a674)

commit 014f9219f1dca3ee92948f0cfcda8d1befa6cbcd
Author: Matthew Daley <mattd@bugfuzz.com>
Date:   Sat Nov 30 13:20:04 2013 +1300

    xenstore: sanity check incoming message body lengths
    
    This is for the client-side receiving messages from xenstored, so there
    is no security impact, unlike XSA-72.
    
    Coverity-ID: 1055449
    Coverity-ID: 1056028
    Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 8da1ed9031341381c218b7e6eaab5b4f239a327b)

commit cfa252b05855a712eda0da80cd638c7093ddf89f
Author: Matthew Daley <mattd@bugfuzz.com>
Date:   Sun Dec 1 23:15:03 2013 +1300

    libxl: don't leak pcidevs in libxl_pcidev_assignable
    
    Coverity-ID: 1055896
    Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 26b35b9ace97f433fcf4c5dfbdfb573d1075255f)

commit d41c205e0173ee923e791c2fd320c7eb25f2e9cb
Author: Matthew Daley <mattd@bugfuzz.com>
Date:   Sun Dec 1 23:15:01 2013 +1300

    libxl: don't leak output vcpu info on error in libxl_list_vcpu
    
    Coverity-ID: 1055887
    Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 3c113a57f55dc4e36e3552342721db01efa832c6)

commit 62f88c08b31259032c81163f4133d6f25f033c1e
Author: Matthew Daley <mattd@bugfuzz.com>
Date:   Sun Dec 1 23:15:00 2013 +1300

    libxl: actually abort if initializing a ctx's lock fails
    
    If initializing the ctx's lock fails, don't keep going, but instead
    error out.
    
    Coverity-ID: 1055289
    Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit b1cb2bdde1f2393d75a925e6c15862b93d3e7abd)

commit c393ff09ade45d1a2a8f1c12eac5eab4d38947a3
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Fri Nov 22 12:54:09 2013 +0100

    xl: fixes for do_daemonize
    
    Fix usage of CHK_ERRNO in do_daemonize and also remove the usage of a
    bogus for(;;).
    
    Coverity-ID: 1130516 and 1130520
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
    (cherry picked from commit ed8c9047f6fc6d28fc27d37576ec8c8c1be68efe)
    
    Conflicts:
    	tools/libxl/xl_cmdimpl.c

commit 8f1bd27fcd7f8be1353e7309f450283f3e5f7cd0
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Fri Nov 22 12:54:08 2013 +0100

    libxl: fix fd check in libxl__spawn_local_dm
    
    Checking the logfile_w fd for -1 on failure is no longer true, because
    libxl__create_qemu_logfile will now return ERROR_FAIL on failure which
    is -3.
    
    While there also add an error check for opening /dev/null.
    
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
    Cc: Andrew Cooper <andrew.cooper3@citrix.com>
    (cherry picked from commit 3b88d95e9c0a5ff91d5b60e94d81f1982af57e7f)
    
    Conflicts:
    	tools/libxl/libxl_dm.c

commit 4cbbbdfb775d387dc1e0931b44e14d3205c92265
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Mon Nov 25 11:12:50 2013 +0000

    tools/libxl: Avoid deliberate NULL pointer dereference
    
    Coverity ID: 1055290
    
    Calling LIBXL__LOG_ERRNO(ctx,) with a ctx pointer we have just failed to
    allocate is going to end badly.  Opencode a suitable use of xtl_log() instead.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    CC: Ian Campbell <Ian.Campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 1677af03c14f2d8d88d2ed9ed8ce6d4906d19fb4)

commit a5febe4aeff4ab80ce0411f63f336c25951098cf
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Mon Nov 25 11:05:49 2013 +0000

    tools/libxc: Improve xc_dom_malloc_filemap() error handling
    
    Coverity ID 1055563
    
    In the original function, mmap() could be called with a length of -1 if the
    second lseek failed and the caller had not provided max_size.
    
    While fixing up this error, improve the logging of other error paths.  I know
    from personal experience that debugging failures function is rather difficult
    given only "xc_dom_malloc_filemap: failed (on file <somefile>)" in the logs.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    CC: Ian Campbell <Ian.Campbell@citrix.com>
    Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    (cherry picked from commit c635c1ef7833e7505423f6567bf99bd355101587)

commit 6f6d936af8acb7d9e36b70e5e70953f695ca3b36
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Mon Nov 25 11:06:39 2013 +0000

    tools/xenconsoled: Fix file handle leaks
    
    Coverity ID: 715218 1055876 1055877
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    CC: Ian Campbell <Ian.Campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit 9ab1792e1ce9e77afe2cd230d69e56a0737a735f)

commit 74cd17f84649012bec7ce484bf7b9c3f3a9e79ae
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Mon Nov 25 11:06:38 2013 +0000

    tools/xenconsole: Use xc_domain_getinfo() correctly
    
    Coverity ID: 1055018
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    CC: Ian Campbell <Ian.Campbell@citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    (cherry picked from commit aa344500a3bfceb3ef01931609ac1cfaf6dcf52d)

commit 2de748569f827b037ec10104f7c12f44d01d0ffa
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Mon Nov 25 11:12:51 2013 +0000

    tools/libxl: Fix integer overflows in sched_sedf_domain_set()
    
    Coverity ID: 1055662 1055663 1055664
    
    Widen from int to uint64_t before multiplcation, rather than afterwards.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    CC: Ian Campbell <Ian.Campbell@citrix.com>
    CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
    (cherry picked from commit 9c01516fee7d548af58fd310d3c93dd71ea9ea28)

commit 338a8b13757d6ef36ff4e321cb4ef4190ba6ec02
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Mon Nov 25 11:16:48 2013 +0000

    tools/libxl: Fix memory leak in sched_domain_output()
    
    Coverity ID: 1055904
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    CC: Keir Fraser <keir@xen.org>
    CC: Jan Beulich <JBeulich@suse.com>
    (cherry picked from commit 0792426b798fd3b39909d618cf8fe8bac30594f4)
    
    Conflicts:
    	tools/libxl/xl_cmdimpl.c
(qemu changes not included)


[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [xen-4.3-testing test] 24332: regressions - FAIL

[Jan Beulich]

>>> On 10.01.14 at 14:11, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 24332 xen-4.3-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/24332/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-oldkern           4 xen-build        fail in 24322 REGR. vs. 22383

So this succeeded in this run, yet blocks the push?

> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore   fail pass in 
> 24322
>  test-armhf-armhf-xl           6 capture-logs(6)  broken in 24322 pass in 
> 24332
> 
> Regressions which are regarded as allowable (not blocking):
>  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail like 24336-bisect

Whereas this one (which iirc blocked the previous two test runs
from doing a push) is now considered allowable?

I'm confused...

Jan

Re: [xen-4.3-testing test] 24332: regressions - FAIL

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [xen-4.3-testing test] 24332: regressions - FAIL"):
> On 10.01.14 at 14:11, xen.org <ian.jackson@eu.citrix.com> wrote:
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  build-amd64-oldkern        4 xen-build     fail in 24322 REGR. vs. 22383
> 
> So this succeeded in this run, yet blocks the push?

Yes, because it needed to consider flight 24322 to justify the next
two failures:

> > Tests which are failing intermittently (not blocking):
> >  test-amd64-amd64-xl-qemuu-win7-amd64  8 guest-saverestore   fail pass in 
> > 24322
> >  test-armhf-armhf-xl           6 capture-logs(6)  broken in 24322 pass in 
> > 24332

And if it disregarded the build failure in 24322 then it might fail to
pay proper attention to an actual regression which was masked
(blocked) by the build failure.

> > Regressions which are regarded as allowable (not blocking):
> >  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail like 24336-bisect
> 
> Whereas this one (which iirc blocked the previous two test runs
> from doing a push) is now considered allowable?

Yes, because 24336 proves it doesn't happen consistently.

Ian.

Re: [xen-4.3-testing test] 24332: regressions - FAIL

[Jan Beulich]

>>> On 10.01.14 at 14:48, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-4.3-testing test] 24332: regressions - FAIL"):
>> On 10.01.14 at 14:11, xen.org <ian.jackson@eu.citrix.com> wrote:
>> > Regressions which are regarded as allowable (not blocking):
>> >  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail like 24336-bisect
>> 
>> Whereas this one (which iirc blocked the previous two test runs
>> from doing a push) is now considered allowable?
> 
> Yes, because 24336 proves it doesn't happen consistently.

Does it? To me it looks like there were only failures since yesterday's
new commits went in - I don't recall having seen a flight report with
this not failing (but then again the names of the tests are similar
enough that I may mix things up).

Jan

Re: [xen-4.3-testing test] 24332: regressions - FAIL

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [xen-4.3-testing test] 24332: regressions - FAIL"):
> On 10.01.14 at 14:48, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> >> Whereas this one (which iirc blocked the previous two test runs
> >> from doing a push) is now considered allowable?
> > 
> > Yes, because 24336 proves it doesn't happen consistently.
> 
> Does it? To me it looks like there were only failures since yesterday's
> new commits went in - I don't recall having seen a flight report with
> this not failing (but then again the names of the tests are similar
> enough that I may mix things up).

You wouldn't have seen 24336 because it was part of an attempt as
bisection.  The bisection flights' reports aren't emailed to xen-devel
because they're very numerous.

> >> >  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail like 24336-bisect

Ian.

Re: [xen-4.3-testing test] 24332: regressions - FAIL

[Jan Beulich]

>>> On 10.01.14 at 14:59, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-4.3-testing test] 24332: regressions - 
> FAIL"):
>> On 10.01.14 at 14:48, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
>> >> Whereas this one (which iirc blocked the previous two test runs
>> >> from doing a push) is now considered allowable?
>> > 
>> > Yes, because 24336 proves it doesn't happen consistently.
>> 
>> Does it? To me it looks like there were only failures since yesterday's
>> new commits went in - I don't recall having seen a flight report with
>> this not failing (but then again the names of the tests are similar
>> enough that I may mix things up).
> 
> You wouldn't have seen 24336 because it was part of an attempt as
> bisection.  The bisection flights' reports aren't emailed to xen-devel
> because they're very numerous.

I understand that.

>> >> >  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail like 24336-bisect

My point was that this says "fail like 24336-bisect", not "failed in
24332, passed in 24336-bisect", i.e. the above only gives
confirmation that there's a problem, not whether some flight had
no problem.

Jan

Re: [xen-4.3-testing test] 24332: regressions - FAIL

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] [xen-4.3-testing test] 24332: regressions - FAIL"):
>>>>  test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install   fail like 24336-bisect
> 
> My point was that this says "fail like 24336-bisect", not "failed in
> 24332, passed in 24336-bisect", i.e. the above only gives
> confirmation that there's a problem, not whether some flight had
> no problem.

24336 will have been a double-check test of the baseline version
carried out by the bisector.  So it gives confirmation that the
problem exists also in the baseline and is therefore not a reason to
block the push.

Ian.