[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/4] tests/qtest: Remove TPM tests
From: |
Stefan Berger |
Subject: |
Re: [PATCH 1/4] tests/qtest: Remove TPM tests |
Date: |
Fri, 15 Jan 2021 14:56:46 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 |
On 1/15/21 1:40 PM, Stefan Berger wrote:
On 1/15/21 11:06 AM, Philippe Mathieu-Daudé wrote:
On 1/15/21 4:53 PM, Stefan Berger wrote:
On 1/15/21 10:52 AM, Philippe Mathieu-Daudé wrote:
Subject is incorrect, this is not a removal of the tests, but
removal of their execution. The tests are still in the repository.
This is more of a disablement.
How do you compile / run them to have the LeakSanitizer checks?
I used:
../configure --cc=clang --enable-sanitizers && make check-qtest
$ clang -v
clang version 10.0.1 (Fedora 10.0.1-3.fc32)
This was previously covered by patchew CI. I just figured
patchew is running without the LeakSanitizer since commit
6f89ec7442e ("docker: test-debug: disable LeakSanitizer"):
docker: test-debug: disable LeakSanitizer
There are just too many leaks in device-introspect-test (especially
for
the plethora of arm and aarch64 boards) to make LeakSanitizer useful;
disable it for now.
I only get short stack traces:
Indirect leak of 852840 byte(s) in 207 object(s) allocated from:
#0 0x561a8c2f8b57 in calloc
(/home/stefanb/tmp/qemu-tip/build/tests/qtest/tpm-crb-swtpm-test+0x23fb57)
#1 0x14f0963069b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0)
#2 0x561a8c4c2508 in json_parser_parse
/home/stefanb/tmp/qemu-tip/build/../qobject/json-parser.c:580:14
#3 0x561a8c4a99aa in json_message_process_token
/home/stefanb/tmp/qemu-tip/build/../qobject/json-streamer.c:92:12
#4 0x561a8c4b6cfb in json_lexer_feed_char
/home/stefanb/tmp/qemu-tip/build/../qobject/json-lexer.c:313:13
Indirect leak of 6624 byte(s) in 207 object(s) allocated from:
#0 0x561a8c2f8b57 in calloc
(/home/stefanb/tmp/qemu-tip/build/tests/qtest/tpm-crb-swtpm-test+0x23fb57)
#1 0x14f0963069b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0)
Indirect leak of 1449 byte(s) in 207 object(s) allocated from:
#0 0x561a8c2f899f in malloc
(/home/stefanb/tmp/qemu-tip/build/tests/qtest/tpm-crb-swtpm-test+0x23f99f)
#1 0x14f096306958 in g_malloc (/lib64/libglib-2.0.so.0+0x58958)
How can I see more of those?
I now added -fno-omit-frame-pointer to configure (should it not be
there?) and it now shows some useful stacktraces.
diff --git a/configure b/configure
index 155dda124c..ed86b5ca32 100755
--- a/configure
+++ b/configure
@@ -5308,7 +5308,7 @@ if test "$gprof" = "yes" ; then
fi
if test "$have_asan" = "yes"; then
- QEMU_CFLAGS="-fsanitize=address $QEMU_CFLAGS"
+ QEMU_CFLAGS="-fsanitize=address -fno-omit-frame-pointer $QEMU_CFLAGS"
QEMU_LDFLAGS="-fsanitize=address $QEMU_LDFLAGS"
if test "$have_asan_iface_h" = "no" ; then
echo "ASAN build enabled, but ASAN header missing." \
diff --git a/tests/qtest/tpm-util.c b/tests/qtest/tpm-util.c
This is my TPM related fix. Maybe it resolve the issue for you also?
index 5a33a6ef0f..b70cc32d60 100644
--- a/tests/qtest/tpm-util.c
+++ b/tests/qtest/tpm-util.c
@@ -250,7 +250,7 @@ void tpm_util_wait_for_migration_complete(QTestState
*who)
status = qdict_get_str(rsp_return, "status");
completed = strcmp(status, "completed") == 0;
g_assert_cmpstr(status, !=, "failed");
- qobject_unref(rsp_return);
+ qobject_unref(rsp);
if (completed) {
return;
}
Now I see ppc64 related leaks:
Direct leak of 200 byte(s) in 1 object(s) allocated from:
#0 0x14c9b743c837 in __interceptor_calloc (/lib64/libasan.so.6+0xb0837)
#1 0x14c9b6e8b9b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0)
#2 0x55c5e7130a1a in qemu_init_vcpu ../softmmu/cpus.c:618
#3 0x55c5e68b30c0 in ppc_cpu_realize
../target/ppc/translate_init.c.inc:10146
#4 0x55c5e7539c08 in device_set_realized ../hw/core/qdev.c:761
#5 0x55c5e714aa38 in property_set_bool ../qom/object.c:2255
#6 0x55c5e7145d52 in object_property_set ../qom/object.c:1400
#7 0x55c5e714f99f in object_property_set_qobject
../qom/qom-qobject.c:28
#8 0x55c5e71465f4 in object_property_set_bool ../qom/object.c:1470
#9 0x55c5e666ae21 in spapr_realize_vcpu ../hw/ppc/spapr_cpu_core.c:254
#10 0x55c5e666ae21 in spapr_cpu_core_realize
../hw/ppc/spapr_cpu_core.c:337
#11 0x55c5e7539c08 in device_set_realized ../hw/core/qdev.c:761
#12 0x55c5e714aa38 in property_set_bool ../qom/object.c:2255
#13 0x55c5e7145d52 in object_property_set ../qom/object.c:1400
#14 0x55c5e714f99f in object_property_set_qobject
../qom/qom-qobject.c:28
#15 0x55c5e71465f4 in object_property_set_bool ../qom/object.c:1470
#16 0x55c5e5c7553c in qdev_device_add ../softmmu/qdev-monitor.c:665
#17 0x55c5e6fd4cc4 in device_init_func ../softmmu/vl.c:1201
#18 0x55c5e78fc7bb in qemu_opts_foreach ../util/qemu-option.c:1147
#19 0x55c5e6fc8912 in qemu_create_cli_devices ../softmmu/vl.c:2488
#20 0x55c5e6fc8912 in qmp_x_exit_preconfig ../softmmu/vl.c:2527
#21 0x55c5e6fcfb4b in qemu_init ../softmmu/vl.c:3533
#22 0x55c5e5b18e78 in main ../softmmu/main.c:49
#23 0x14c9b50fa041 in __libc_start_main (/lib64/libc.so.6+0x27041)
[..]
Stefan
- [PATCH 0/4] tests/qtest: Fixes fuzz-tests, Philippe Mathieu-Daudé, 2021/01/15
- [PATCH 2/4] tests/qtest: Make fuzz-test generic to all targets, Philippe Mathieu-Daudé, 2021/01/15
- [PATCH 1/4] tests/qtest: Remove TPM tests, Philippe Mathieu-Daudé, 2021/01/15
- Re: [PATCH 1/4] tests/qtest: Remove TPM tests, Philippe Mathieu-Daudé, 2021/01/15
- Re: [PATCH 1/4] tests/qtest: Remove TPM tests, Stefan Berger, 2021/01/15
- Re: [PATCH 1/4] tests/qtest: Remove TPM tests, Philippe Mathieu-Daudé, 2021/01/15
- Re: [PATCH 1/4] tests/qtest: Remove TPM tests, Philippe Mathieu-Daudé, 2021/01/15
- Re: [PATCH 1/4] tests/qtest: Remove TPM tests, Stefan Berger, 2021/01/15
- Re: [PATCH 1/4] tests/qtest: Remove TPM tests,
Stefan Berger <=
- Re: [PATCH 1/4] tests/qtest: Remove TPM tests, Philippe Mathieu-Daudé, 2021/01/16
Re: [PATCH 1/4] tests/qtest: Remove TPM tests, Paolo Bonzini, 2021/01/17
[PATCH 3/4] tests/qtest: Only run fuzz-megasas-test if megasas device is available, Philippe Mathieu-Daudé, 2021/01/15
[PATCH 4/4] tests/qtest: Only run fuzz-virtio-scsi when virtio-scsi is available, Philippe Mathieu-Daudé, 2021/01/15