restructure results

1 files changed, 0 insertions, 86 deletions

diff --git a/results/classifier/108/none/1824331 b/results/classifier/108/none/1824331
deleted file mode 100644
index 3226a2bb..00000000
--- a/results/classifier/108/none/1824331
+++ /dev/null
@@ -1,86 +0,0 @@
-other: 0.584
-device: 0.539
-network: 0.506
-semantic: 0.501
-performance: 0.499
-graphic: 0.491
-debug: 0.480
-KVM: 0.469
-permissions: 0.452
-PID: 0.446
-socket: 0.432
-files: 0.417
-vnc: 0.409
-boot: 0.392
-
-Qemu Crashes
-
-A high volume of communication (UDPv4) between the host and Qemu causes it to crash.
-Qemu version: 2.11.1
-Ubuntu 18.04.1 LTS
-
-I attached GDB to the Qemu but wasn't able to get the debug symbols working.
-Some more assistance with how to get this working is appreciated (I am new to all of this).
-
-I recorded two different situations where it happened. Both seem to be related to the network.
-
-#0  0x00007fa065fb6e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
-#1  0x00007fa065fb8801 in __GI_abort () at abort.c:79
-#2  0x00007fa066001897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fa06612eb9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181
-#3  0x00007fa06600890a in malloc_printerr (str=str@entry=0x7fa06612ccba "corrupted double-linked list") at malloc.c:5350
-#4  0x00007fa066008ac4 in malloc_consolidate (av=av@entry=0x7fa04c000020) at malloc.c:4456
-#5  0x00007fa06600c7d8 in _int_malloc (av=av@entry=0x7fa04c000020, bytes=bytes@entry=8192) at malloc.c:3703
-#6  0x00007fa06600f2ed in __GI___libc_malloc (bytes=8192) at malloc.c:3065
-#7  0x0000555c8d2edee8 in sbreserve ()
-#8  0x0000555c8d2f06f9 in tcp_input ()
-#9  0x0000555c8d2ec990 in slirp_input ()
-#10 0x0000555c8d2dc760 in  ()
-#11 0x0000555c8d2d453d in qemu_deliver_packet_iov ()
-#12 0x0000555c8d2d7392 in qemu_net_queue_send ()
-#13 0x0000555c8d2d46f6 in  ()
-#14 0x0000555c8d21e4e6 in  ()
-#15 0x0000555c8d21f7ab in  ()
-#16 0x0000555c8d21fc30 in  ()
-#17 0x0000555c8d056b68 in  ()
-#18 0x0000555c8d053ffe in  ()
-#19 0x0000555c8d058ae7 in memory_region_dispatch_write ()
-#20 0x0000555c8d014d3e in  ()
-#21 0x0000555c8d0677d8 in kvm_cpu_exec ()
-#22 0x0000555c8d044404 in  ()
-#23 0x00007fa0663706db in start_thread (arg=0x7fa056ffd700) at pthread_create.c:463
-#24 0x00007fa06609988f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
-
-
-#0  0x00007f6b3b8f4e97 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
-#1  0x00007f6b3b8f6801 in __GI_abort () at abort.c:79
-#2  0x00007f6b3b93f897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f6b3ba6cb9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181
-#3  0x00007f6b3b94690a in malloc_printerr (str=str@entry=0x7f6b3ba6aed3 "realloc(): invalid next size") at malloc.c:5350
-#4  0x00007f6b3b94b9b4 in _int_realloc (av=av@entry=0x7f6b1c000020, oldp=oldp@entry=0x7f6b1c03d8a0, oldsize=oldsize@entry=38560, nb=nb@entry=40032) at malloc.c:4534
-#5  0x00007f6b3b94ef9b in __GI___libc_realloc (oldmem=0x7f6b1c03d8b0, bytes=40024) at malloc.c:3230
-#6  0x00007f6b3c6d5ae0 in g_realloc () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
-#7  0x000055dd0f5e6f50 in  ()
-#8  0x000055dd0f5e7238 in m_cat ()
-#9  0x000055dd0f5e44f1 in ip_input ()
-#10 0x000055dd0f5e6990 in slirp_input ()
-#11 0x000055dd0f5d6760 in  ()
-#12 0x000055dd0f5ce53d in qemu_deliver_packet_iov ()
-#13 0x000055dd0f5d1392 in qemu_net_queue_send ()
-#14 0x000055dd0f5ce6f6 in  ()
-#15 0x000055dd0f5184e6 in  ()
-#16 0x000055dd0f5197ab in  ()
-#17 0x000055dd0f519c30 in  ()
-#18 0x000055dd0f350b68 in  ()
-#19 0x000055dd0f34dffe in  ()
-#20 0x000055dd0f352ae7 in memory_region_dispatch_write ()
-#21 0x000055dd0f30ed3e in  ()
-#22 0x000055dd0f3617d8 in kvm_cpu_exec ()
-#23 0x000055dd0f33e404 in  ()
-#24 0x00007f6b3bcae6db in start_thread (arg=0x7f6b30f17700) at pthread_create.c:463
-#25 0x00007f6b3b9d788f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
-
-Could you try reproducing this with the QEMU 4.0 rc3 which we've just put out, please? I have a vague recollection that we fixed a memory leak in the slirp networking in this area.
-
-
-We tested our situation with Qemu 4.0 and we are unable to reproduce the issue.
-So it looks like the issue has been fixed in a more recent version.
-