|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable-smoke test] 93010: regressions - FAIL
flight 93010 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/93010/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 9 debian-install fail REGR. vs. 92992 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-check fail never pass version targeted for testing: xen c106e5b039c712fc7b6f3ce3c82d367de09b8d98 baseline version: xen e2faa286faa36da36ee14f6bc973043013001724 Last test of basis 92992 2016-04-27 17:14:57 Z 0 days Testing same since 93010 2016-04-27 20:01:14 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Doug Goldstein <cardoe@xxxxxxxxxx> Wei Liu <wei.liu2@xxxxxxxxxx> jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt 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 c106e5b039c712fc7b6f3ce3c82d367de09b8d98 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Apr 27 14:06:04 2016 +0100 travis: Enable tools when building with clang tools now build under clang, so let them be tested. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by: Doug Goldstein <cardoe@xxxxxxxxxx> commit 81aa61195c8f670a24e105f25832a8f9006ee800 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Apr 27 17:10:57 2016 +0100 travis: Remove clang-3.8 build The package appears to have been renamed in Ubuntu. The only reason this test is currently passing is because the hypervisor build falls back to clang, at version 3.5 Add an explicit test in the build script that out desired compiler is available. Note that travis already performs this step, but in a way which isn't fatal to the build. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by Doug Goldstein <cardoe@xxxxxxxxxx> commit bec4135fdca2538263abb1b552ec2c69539b04c2 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Apr 27 13:58:27 2016 +0100 tools/kdd: Fix uninitialised variable warning Clang warns: kdd.c:1031:9: error: variable 'fd' is used uninitialized whenever '||' condition is true [-Werror,-Wsometimes-uninitialized] if (argc != 4 ^~~~~~~~~ kdd.c:1040:20: note: uninitialized use occurs here if (select(fd + 1, &fds, NULL, NULL, NULL) > 0) ^~ This situation can't actually happen, as usage() is a terminal path. Annotate it appropriately. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Reviewed-by: Doug Goldstein <cardoe@xxxxxxxxxx> commit ca4c1848f128e3aeb8a79945137d6b2bc710ba93 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Apr 27 13:31:05 2016 +0100 tools/blktap2: Fix use of uninitialised variable in _tap_list_join3() Clang points out: tap-ctl-list.c:457:28: error: variable 'entry' is uninitialized when used here [-Werror,-Wuninitialized] for (; *_entry != NULL; ++entry) { ^~~~~ The content of that loop clearly was meant to iterate over _entry rather than entry, so is fixed to do so. This presumably fixes a memory leak when tapdisks get orphed, as only the first item on the list got freed. There is no use of entry at all. It is referenced in a list_for_each_entry(tl, &tap->list, entry) construct, but this is just a member name, and not a reference to local scope variable of the same name. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Reviewed-by: Doug Goldstein <cardoe@xxxxxxxxxx> commit 05fc4ef8ae3e99e8a26cffb2bc9ea22c306fb5fe Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Apr 27 11:23:04 2016 +0100 tools/blktap2: Fix array initialisers for tapdisk_disk_{types,drivers}[] Clang points out: tapdisk-disktype.c:117:2: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides] 0, ^ tapdisk-disktype.c:115:23: note: previous initialization is here [DISK_TYPE_VINDEX] = &vhd_index_disk, ^~~~~~~~~~~~~~~ Mixing different initialiser styles should be avoided; The actual behaviour is different to the expected behaviour. This specific example has been broken since its introduction in c/s 7b4dea554 "blktap2: Fix tapdisk disktype issues" in 2010, and is caused by the '#if 0' block removing &tapdisk_{sync,vmdk}. First of all, remove what were intended to be trailing NULL entries in tapdisk_disk_{types,drivers}[], making consistent use of Designated Initialisers for the initialisation. This requires changing the loop in tapdisk_disktype_find() to be based on the number of elements in tapdisk_disk_types[], rather than looking for the first NULL. This fixes a latent bug, as the use of Designated Initializers causes to intermediate zero entries if not all indices are explicitly specified. There is a second latent bug where tapdisk_disktype_find() assumes that tapdisk_disk_drivers[] has at least as many entries as tapdisk_disk_types[]. This is not the case and tapdisk_disk_drivers[] had one entry fewer than tapdisk_disk_types[], but the NULL loop bound prevented an out-of-bounds read of tapdisk_disk_drivers[]. Fix the issue by explicitly declaring tapdisk_disk_drivers[] to have the same number of entries as tapdisk_disk_types[]. Finally, this leads to a linker error. It turns out that tapdisk_vhd_index doesn't exist, and I can't find any evidence in the source history to suggest that it ever did. I can only presume that it would have been #if 0'd out like tapdisk_sync and tapdisk_vmdk had it not been for this bug preventing a build failure. Drop all three. No functional change, but only because of the specific layout of tapdisk_disk_types[]. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Reviewed-by: Doug Goldstein <cardoe@xxxxxxxxxx> commit ddde10ac178bea2b9094371dd51ff7b5ea7f6ee3 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Apr 27 11:33:42 2016 +0100 tools/blktap2: Use abort() instead of custom crash Like c/s 4d98d3ebf - there is a second instance. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> commit 9b0f436327c855546900c7fcf30e07aef9d4f2b0 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Wed Apr 27 11:01:03 2016 +0100 tools/xenstat: Avoid comparing '0 <= unsigned integer' Clang points out that this is tautological. src/xenstat.c:325:8: warning: comparison of 0 <= unsigned expression is always true [-Wtautological-compare] if (0 <= index && index < node->num_domains) ~ ^ ~~~~~ Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |