|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [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> _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/cgi-bin/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |