[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [libvirt test] 107353: regressions - FAIL



flight 107353 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107353/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  4 host-ping-check-native   fail REGR. vs. 107325

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt     13 saverestore-support-check    fail  like 107325
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check    fail  like 107325

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)               blocked  n/a
 test-arm64-arm64-libvirt      1 build-check(1)               blocked  n/a
 build-arm64-pvops             5 kernel-build                 fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt     12 migrate-support-check        fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check        fail   never pass
 test-amd64-i386-libvirt      12 migrate-support-check        fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-check        fail   never pass

version targeted for testing:
 libvirt              fd6e3f48ede2e3a01ef849ea4411d6507515956e
baseline version:
 libvirt              4c661a944d75638db76483bbd058981b4c0595a8

Last test of basis   107325  2017-04-09 17:17:18 Z    1 days
Testing same since   107353  2017-04-10 16:31:08 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  John Ferlan <jferlan@xxxxxxxxxx>
  Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-arm64-xsm                                              pass    
 build-armhf-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-arm64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-arm64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-arm64-pvops                                            fail    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm           pass    
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm            pass    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-arm64-arm64-libvirt-xsm                                 blocked 
 test-armhf-armhf-libvirt-xsm                                 pass    
 test-amd64-i386-libvirt-xsm                                  pass    
 test-amd64-amd64-libvirt                                     pass    
 test-arm64-arm64-libvirt                                     blocked 
 test-armhf-armhf-libvirt                                     pass    
 test-amd64-i386-libvirt                                      pass    
 test-amd64-amd64-libvirt-pair                                pass    
 test-amd64-i386-libvirt-pair                                 pass    
 test-arm64-arm64-libvirt-qcow2                               blocked 
 test-armhf-armhf-libvirt-raw                                 fail    
 test-amd64-amd64-libvirt-vhd                                 pass    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Not pushing.

------------------------------------------------------------
commit fd6e3f48ede2e3a01ef849ea4411d6507515956e
Author: Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx>
Date:   Mon Apr 3 10:24:39 2017 +0200

    refactoring: Use the return value of virObjectRef directly
    
    Use the return value of virObjectRef directly. This way, it's easier
    for another reader to identify the reason why the additional reference
    is required.
    
    Signed-off-by: Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx>
    Reviewed-by: Bjoern Walk <bwalk@xxxxxxxxxxxxxxxxxx>

commit 7a665f24514ae83767fd03c1b2c6fac47f3ef686
Author: Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx>
Date:   Mon Apr 3 10:24:38 2017 +0200

    qemu: remove ATTRIBUTE_UNUSED in qemuProcessHandleMonitorEOF
    
    This attribute is not needed here, since @mon is in use.
    
    Signed-off-by: Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx>
    Reviewed-by: Bjoern Walk <bwalk@xxxxxxxxxxxxxxxxxx>

commit bae81da323c3563d4e435e23055379314da0a7f1
Author: Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx>
Date:   Mon Apr 3 10:24:37 2017 +0200

    qemu: Implement qemuMonitorRegister()
    
    Implement qemuMonitorRegister() as there is already a
    qemuMonitorUnregister() function. This way it may be easier to
    understand the code paths.
    
    Signed-off-by: Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx>
    Reviewed-by: Bjoern Walk <bwalk@xxxxxxxxxxxxxxxxxx>

commit b8cc5098822c9ff77aa9b4b036fed7b9a3485659
Author: Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx>
Date:   Mon Apr 3 10:24:36 2017 +0200

    qemu: Turn qemuDomainLogContext into virObject
    
    This way qemuDomainLogContextRef() and qemuDomainLogContextFree() is
    no longer needed. The naming qemuDomainLogContextFree() was also
    somewhat misleading. Additionally, it's easier to turn
    qemuDomainLogContext in a self-locking object.
    
    Signed-off-by: Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx>
    Reviewed-by: Bjoern Walk <bwalk@xxxxxxxxxxxxxxxxxx>

commit 20e95cb7c8653b02016ab9a7118c6de8c9866ea9
Author: Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx>
Date:   Mon Apr 3 10:24:35 2017 +0200

    qemu: Fix two use-after-free situations
    
    There were multiple race conditions that could lead to segmentation
    faults. The first precondition for this is qemuProcessLaunch must fail
    sometime shortly after starting the new QEMU process. The second
    precondition for the segmentation faults is that the new QEMU process
    dies - or to be more precise the QEMU monitor has to be closed
    irregularly. If both happens during qemuProcessStart (starting a
    domain) there are race windows between the thread with the event
    loop (T1) and the thread that is starting the domain (T2).
    
    First segmentation fault scenario:
    If qemuProcessLaunch fails during qemuProcessStart the code branches
    to the 'stop' path where 'qemuMonitorSetDomainLog(priv->mon, NULL,
    NULL, NULL)' will set the log function of the monitor to NULL (done in
    T2). In the meantime the event loop of T1 will wake up with an EOF
    event for the QEMU monitor because the QEMU process has died. The
    crash occurs if T1 has checked 'mon->logFunc != NULL' in qemuMonitorIO
    just before the logFunc was set to NULL by T2. If this situation
    occurs T1 will try to call mon->logFunc which leads to the
    segmentation fault.
    
    Solution:
    Require the monitor lock for setting the log function.
    
    Backtrace:
    0  0x0000000000000000 in ?? ()
    1  0x000003ffe9e45316 in qemuMonitorIO (watch=<optimized out>,
    fd=<optimized out>, events=<optimized out>, opaque=0x3ffe08aa860) at
    ../../src/qemu/qemu_monitor.c:727
    2  0x000003fffda2e1a4 in virEventPollDispatchHandles (nfds=<optimized
    out>, fds=0x2aa000fd980) at ../../src/util/vireventpoll.c:508
    3  0x000003fffda2e398 in virEventPollRunOnce () at
    ../../src/util/vireventpoll.c:657
    4  0x000003fffda2ca10 in virEventRunDefaultImpl () at
    ../../src/util/virevent.c:314
    5  0x000003fffdba9366 in virNetDaemonRun (dmn=0x2aa000cc550) at
    ../../src/rpc/virnetdaemon.c:818
    6  0x000002aa00024668 in main (argc=<optimized out>, argv=<optimized
    out>) at ../../daemon/libvirtd.c:1541
    
    Second segmentation fault scenario:
    If qemuProcessLaunch fails it will unref the log context and with
    invoking qemuMonitorSetDomainLog(priv->mon, NULL, NULL, NULL)
    qemuDomainLogContextFree() will be invoked. qemuDomainLogContextFree()
    invokes virNetClientClose() to close the client and cleans everything
    up (including unref of _virLogManager.client) when virNetClientClose()
    returns. When T1 is now trying to report 'qemu unexpectedly closed the
    monitor' libvirtd will crash because the client has already been
    freed.
    
    Solution:
    As the critical section in qemuMonitorIO is protected with the monitor
    lock we can use the same solution as proposed for the first
    segmentation fault.
    
    Backtrace:
    0  virClassIsDerivedFrom (klass=0x3100979797979797,
    parent=0x2aa000d92f0) at ../../src/util/virobject.c:169
    1  0x000003fffda659e6 in virObjectIsClass (anyobj=<optimized out>,
    klass=<optimized out>) at ../../src/util/virobject.c:365
    2  0x000003fffda65a24 in virObjectLock (anyobj=0x3ffe08c1db0) at
    ../../src/util/virobject.c:317
    3  0x000003fffdba4688 in
    virNetClientIOEventLoop (client=client@entry=0x3ffe08c1db0,
    thiscall=thiscall@entry=0x2aa000fbfa0) at
    ../../src/rpc/virnetclient.c:1668
    4  0x000003fffdba4b4c in
    virNetClientIO (client=client@entry=0x3ffe08c1db0,
    thiscall=0x2aa000fbfa0) at ../../src/rpc/virnetclient.c:1944
    5  0x000003fffdba4d42 in
    virNetClientSendInternal (client=client@entry=0x3ffe08c1db0,
    msg=msg@entry=0x2aa000cc710, expectReply=expectReply@entry=true,
    nonBlock=nonBlock@entry=false) at ../../src/rpc/virnetclient.c:2116
    6  0x000003fffdba6268 in
    virNetClientSendWithReply (client=0x3ffe08c1db0, msg=0x2aa000cc710) at
    ../../src/rpc/virnetclient.c:2144
    7  0x000003fffdba6e8e in virNetClientProgramCall (prog=0x3ffe08c1120,
    client=<optimized out>, serial=<optimized out>, proc=<optimized out>,
    noutfds=<optimized out>, outfds=0x0, ninfds=0x0, infds=0x0,
    args_filter=0x3fffdb64440
    <xdr_virLogManagerProtocolDomainReadLogFileArgs>, args=0x3ffffffe010,
    ret_filter=0x3fffdb644c0
    <xdr_virLogManagerProtocolDomainReadLogFileRet>, ret=0x3ffffffe008) at
    ../../src/rpc/virnetclientprogram.c:329
    8  0x000003fffdb64042 in
    virLogManagerDomainReadLogFile (mgr=<optimized out>, path=<optimized
    out>, inode=<optimized out>, offset=<optimized out>, maxlen=<optimized
    out>, flags=0) at ../../src/logging/log_manager.c:272
    9  0x000003ffe9e0315c in qemuDomainLogContextRead (ctxt=0x3ffe08c2980,
    msg=0x3ffffffe1c0) at ../../src/qemu/qemu_domain.c:4422
    10 0x000003ffe9e280a8 in qemuProcessReadLog (logCtxt=<optimized out>,
    msg=msg@entry=0x3ffffffe288) at ../../src/qemu/qemu_process.c:1800
    11 0x000003ffe9e28206 in qemuProcessReportLogError (logCtxt=<optimized
    out>, msgprefix=0x3ffe9ec276a "qemu unexpectedly closed the monitor")
    at ../../src/qemu/qemu_process.c:1836
    12 0x000003ffe9e28306 in
    qemuProcessMonitorReportLogError (mon=mon@entry=0x3ffe085cf10,
    msg=<optimized out>, opaque=<optimized out>) at
    ../../src/qemu/qemu_process.c:1856
    13 0x000003ffe9e452b6 in qemuMonitorIO (watch=<optimized out>,
    fd=<optimized out>, events=<optimized out>, opaque=0x3ffe085cf10) at
    ../../src/qemu/qemu_monitor.c:726
    14 0x000003fffda2e1a4 in virEventPollDispatchHandles (nfds=<optimized
    out>, fds=0x2aa000fd980) at ../../src/util/vireventpoll.c:508
    15 0x000003fffda2e398 in virEventPollRunOnce () at
    ../../src/util/vireventpoll.c:657
    16 0x000003fffda2ca10 in virEventRunDefaultImpl () at
    ../../src/util/virevent.c:314
    17 0x000003fffdba9366 in virNetDaemonRun (dmn=0x2aa000cc550) at
    ../../src/rpc/virnetdaemon.c:818
    18 0x000002aa00024668 in main (argc=<optimized out>, argv=<optimized
    out>) at ../../daemon/libvirtd.c:1541
    
    Other code parts where the same problem was possible to occur are
    fixed as well (qemuMigrationFinish, qemuProcessStart, and
    qemuDomainSaveImageStartVM).
    
    Signed-off-by: Marc Hartmayer <mhartmay@xxxxxxxxxxxxxxxxxx>
    Reported-by: Sascha Silbe <silbe@xxxxxxxxxxxxxxxxxx>

commit 6f143cc5bb8ae7ca79c3c95d7b7afef5b55c97ed
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Mon Mar 20 07:28:30 2017 -0400

    nodedev: Pass driver arg by ref
    
    Alter virNodeDeviceObjListExport in order to pass the drivers->devs
    by reference
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit d06d1a329db1edd8f7851c4e2ed855053a5802ce
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Sun Mar 19 15:51:03 2017 -0400

    nodedev: Introduce virNodeDeviceObjGetNames
    
    Unify the *ListDevice API into virnodedeviceobj.c from node_device_driver
    and test_driver.  The only real difference between the two is that the test
    driver doesn't call the aclfilter API. The name of the new API follows that
    of other drivers to "GetNames".
    
    NB: Change some variable names to match what they really are - consistency
    with other drivers. Also added a clear of the input names.
    
    This also allows virNodeDeviceObjHasCap to be static to virnodedeviceobj
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit be3c2dfd1a2310ed7725c4f4bb009d94863fed07
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Sun Mar 19 07:49:38 2017 -0400

    nodedev: Introduce virNodeDeviceObjNumOfDevices
    
    Unify the NumOfDevices API into virnodedeviceobj.c from node_device_driver
    and test_driver.  The only real difference between the two is that the test
    driver doesn't call the aclfilter API.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit 4fba40159fc2eb246fa947e2c5e5fa10cfbd9054
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Thu Apr 6 09:46:43 2017 -0400

    interface: Clean up Interface section of test_driver
    
    Clean up the code to adhere to more of the standard two spaces between
    functions, separate lines for type and function name, one argument per line.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit a9d33be34e5f402d5810f2e33415a27448d8b0ba
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Thu Apr 6 09:37:57 2017 -0400

    interface: Introduce virInterfaceObjGetNames
    
    Unlike other drivers, this is a test driver only API. Still combining
    the logic of testConnectListInterfaces and testConnectListDefinedInterfaces
    makes things a bit easier in the long run.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

commit 7dc4513808b7c6dae8b1c2ddfd7dd4007d1bf34e
Author: John Ferlan <jferlan@xxxxxxxxxx>
Date:   Thu Apr 6 09:23:17 2017 -0400

    interface: Introduce virInterfaceObjNumOfInterfaces
    
    Unlike other drivers, this is a test driver only API. Still combining
    the logic of testConnectNumOfInterfaces and 
testConnectNumOfDefinedInterfaces
    makes things a bit easier in the long run.
    
    Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.