diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1890 | 40 | ||||
| -rw-r--r-- | results/classifier/108/other/1890069 | 168 | ||||
| -rw-r--r-- | results/classifier/108/other/1890152 | 73 | ||||
| -rw-r--r-- | results/classifier/108/other/1890155 | 64 | ||||
| -rw-r--r-- | results/classifier/108/other/1890312 | 86 | ||||
| -rw-r--r-- | results/classifier/108/other/1890333 | 170 | ||||
| -rw-r--r-- | results/classifier/108/other/1890370 | 90 | ||||
| -rw-r--r-- | results/classifier/108/other/1890395 | 184 | ||||
| -rw-r--r-- | results/classifier/108/other/1890545 | 407 | ||||
| -rw-r--r-- | results/classifier/108/other/1890775 | 72 |
10 files changed, 1354 insertions, 0 deletions
diff --git a/results/classifier/108/other/1890 b/results/classifier/108/other/1890 new file mode 100644 index 000000000..ab54b53ad --- /dev/null +++ b/results/classifier/108/other/1890 @@ -0,0 +1,40 @@ +graphic: 0.770 +device: 0.752 +PID: 0.714 +files: 0.704 +debug: 0.696 +vnc: 0.695 +semantic: 0.672 +socket: 0.662 +permissions: 0.659 +performance: 0.644 +network: 0.580 +boot: 0.514 +KVM: 0.277 +other: 0.184 + +qemu-arm 8.1.0 Error mapping file: Operation not permitted +Description of problem: +failed to execute the cortex-m binary hello_world, and says: +qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted +Steps to reproduce: +1. +``` +cat > hello_new.c <<EOF +#include <stdio.h> +int main() +{printf("hello world"); return 0;} +EOF +``` +2. +``` +arm-none-eabi-gcc -mcpu=cortex-m55 -g hello_world.c -o hello_world -specs=rdimon.specs +``` +3. +``` +qemu-arm -cpu cortex-m55 hello_world +qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted +``` +Additional information: +1, version 8.0.4 version is okay\ +2, arm-none-eabi-gcc version is 10.3.1 20210824 (release) diff --git a/results/classifier/108/other/1890069 b/results/classifier/108/other/1890069 new file mode 100644 index 000000000..fb40b3d71 --- /dev/null +++ b/results/classifier/108/other/1890069 @@ -0,0 +1,168 @@ +other: 0.927 +semantic: 0.919 +graphic: 0.909 +debug: 0.906 +permissions: 0.891 +network: 0.874 +device: 0.865 +PID: 0.864 +performance: 0.863 +vnc: 0.861 +files: 0.852 +KVM: 0.849 +boot: 0.843 +socket: 0.810 + +QEMU is not allowing multiple cores with mips architecture + +I may have found a bug as when trying to boot up an QEMU VM with the following command: "qemu-system-mips -M malta -m 512 -hda hda.img -kernel vmlinux-4.19.0-10-4kc-malta -initrd initrd.img-4.19.0-10-4kc-malta -append "root=/dev/sda1 console=ttyS0" -nographic -device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22 -smp cores=12,threads=1,sockets=1", it will use up all of the CPU cores on the host, but not bootup? + +Kernel log also shows: +[ 100.303136] perf: interrupt took too long (2506 > 2500), lowering kernel.perf_event_max_sample_rate to 79750 +[ 107.656869] perf: interrupt took too long (3195 > 3132), lowering kernel.perf_event_max_sample_rate to 62500 +[ 117.668390] perf: interrupt took too long (4033 > 3993), lowering kernel.perf_event_max_sample_rate to 49500 +[ 217.166763] perf: interrupt took too long (5126 > 5041), lowering kernel.perf_event_max_sample_rate to 39000 +[ 231.910132] perf: interrupt took too long (6445 > 6407), lowering kernel.perf_event_max_sample_rate to 31000 +[ 250.170677] perf: interrupt took too long (8087 > 8056), lowering kernel.perf_event_max_sample_rate to 24500 +[ 285.391451] perf: interrupt took too long (10126 > 10108), lowering kernel.perf_event_max_sample_rate to 19750 +[ 778.588911] perf: interrupt took too long (12770 > 12657), lowering kernel.perf_event_max_sample_rate to 15500 +[ 1554.825129] perf: interrupt took too long (15982 > 15962), lowering kernel.perf_event_max_sample_rate to 12500 +[ 1622.838910] hrtimer: interrupt took 14758063 ns +[ 1712.932777] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 0.000 msecs +[ 1712.932780] perf: interrupt took too long (59793 > 19977), lowering kernel.perf_event_max_sample_rate to 3250 + + +System details: + +OS: Ubuntu 20.04 +QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu6.3) + +Hi Skyler, +mips emulation is rather rare - so there is always a chance that something broke without being recognized at first. For a start let me ask a few questions to corner the issue: + +1. did that work before and is a regression in the qemu 4.2 of Ubuntu? +2. check other versions - could you try the same with qemu 3.1 (Bionic) and 5.0 (groovy) of Ubuntu if it is the same? +3. after we know of the above if new/old versions were ok it could be worth checking pristine upstream qemu builds to see if any delta in Ubuntu has to be fixed. Depending on your time and ability to do so would you be able to build from tags of https://git.qemu.org/?p=qemu.git? +(TL;DR; add deb-src lines in /etc/apt/sources.list, apt build-dep qemu; + +In general maybe attach the kernel/initrd of your test so others can try the same. +I assume you used something like http://ftp.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/ ? + +Once that is sorted we know better if we look at a "how to use question" or an actual bug - and for the latter if it is a regression of some sort (which would make us hunt for the offending change). + +I was quickly giving things a check but don't have the time to do the full matrix: + +The old bits from https://people.debian.org/~aurel32/qemu/mipsel/ +$ qemu-system-mips64el -M malta -kernel vmlinux-3.2.0-4-4kc-malta -nographic -curses + +Later the kernels are more obviously split (mipsel/mips64/mips64el) build at https://people.debian.org/~jcowgill/qemu-mips/ +I can get to run with: +$ qemu-system-mips64el -M malta -cpu MIPS64R2-generic -m 2G -kernel vmlinux-4.15.0-1-5kc-malta.mips64el.sid -nographic -curses +$ qemu-system-mips64el -M malta -cpu MIPS64R2-generic -m 2G -kernel vmlinux-4.15.0-1-5kc-malta.mipsel.sid -nographic -curses +$ qemu-system-mips64 -M malta -cpu MIPS64R2-generic -m 2G -kernel vmlinux-4.15.0-1-5kc-malta.mips.sid -nographic -curses + +Zoning in to something close to your kernel that you've tried from http://ftp.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/ +works with: +$ qemu-system-mips64 -M malta -cpu MIPS64R2-generic -m 2G -kernel vmlinux-4.19.0-10-4kc-malta -nographic -curses + +From here I was slowly getting more similar to your commandline. +Sill works: +$ qemu-system-mips -M malta -m 2G -kernel vmlinux-4.19.0-10-4kc-malta -nographic -curses +add initrd: +$ qemu-system-mips -M malta -m 2G -kernel vmlinux-4.19.0-10-4kc-malta -initrd initrd-4.19.0-10-4kc-$malta.gz -nographic -curses +Add net: +$ qemu-system-mips -M malta -m 2G -kernel vmlinux-4.19.0-10-4kc-malta -initrd initrd-4.19.0-10-4kc-malta.gz -nographic -curses -nographic -device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22 +reduce memory: +$ qemu-system-mips -M malta -m 512 -kernel vmlinux-4.19.0-10-4kc-malta -initrd initrd-4.19.0-10-4kc-malta.gz -nographic -curses -nographic -device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22 +kernel commandline: +$ qemu-system-mips -M malta -m 512 -kernel vmlinux-4.19.0-10-4kc-malta -initrd initrd-4.19.0-10-4kc-malta.gz -nographic -curses -nographic -device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22 -append "root=/dev/sda1 console=ttyS0" + +All that worked, what got it stuck was the smp option that you used. +-smp 1 works +-smp 2 works +-smp 3 stuck +-smp 4 stuck + qemu-system-mips: /build/qemu-BQ4hMP/qemu-4.2/hw/acpi/cpu.c:198: cpu_hotplug_hw_init: Assertion + `mc->possible_cpu_arch_ids' failed. + Aborted (core dumped) +-smp 4 stuck (retry) +[ 0.000000] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: (null) + +With more memory I get slightly further until stuck, up to -smp 12 things won't get better. + + +Not sure how good/bad smp is in emulated mips - we are back to my initial question - did this work in the past and regressed - or is it instead an upstream feature request for (better) mips emu SMP? + +These are old, but might still be true: +https://lists.gnu.org/archive/html/qemu-devel/2013-06/msg04436.html +https://qemu-devel.nongnu.narkive.com/m6BNDsfR/does-qemu-support-mips-smp2-malta-board +https://<email address hidden>/msg10710.html + +If that is it then that is a natural limitation. + +The only bit I've seen mentioning >2 to work is +https://www.mips.com/blog/how-to-run-smp-linux-in-qemu-on-a-mips64-release-6-cpu/ + +But the I6400 cpu doesn't exist with newer qemus I7200 does but doesn't work either. +This seems like an upstream feature request to me, but one that was mostly denied 7 years ago (by architecture unable to do so). + +Let me know if this is a regression and if I missed something. +Otherwise yeah - you could start a new upstream discussion, but no promises it will end any different than the past ones. + +This hasn't worked at any point yet, as I'm trying to emulate MIPS that has more than one core that it can use for a workload. + +Images used: +http://ftp.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/initrd.gz +http://ftp.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/vmlinux-4.19.0-10-4kc-malta + +I don't know if -smp is the right thing to use for it to begin with, but that's the only thing I found that's even close to getting more cores to the system. + +My hardware that's running MIPS, is MIPS 1004Kc V2.15, and it has 4 cores. I'm trying to emulate it with QEMU. + +----------------------------------------------------------------------------------------------- +processor : 3 +cpu model : MIPS 1004Kc V2.15 +BogoMIPS : 581.63 +wait instruction : yes +microsecond timers : yes +tlb_entries : 32 +extra interrupt vector : yes +hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb] +isa : mips1 mips2 mips32r1 mips32r2 +ASEs implemented : mips16 dsp mt +shadow register sets : 1 +kscratch registers : 0 +package : 0 +core : 1 +VPE : 1 +VCED exceptions : not available +VCEI exceptions : not available +----------------------------------------------------------------------------------------------- + + +How can I test qemu 5.0 as groovy has not been released yet? + +Q: How can I test qemu 5.0 as groovy has not been released yet? +A: you can get that already, depending on your preferred way to deploy there are different options: + +You can download a daily build of the ISO: +http://cdimage.ubuntu.com/daily-live/current/ +http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/ + +Cloud-images: +https://cloud-images.ubuntu.com/groovy/current/ + +Or you can upgrade a system that you already have via: +(I assume you do so from 20.04) +set in /etc/update-manager/release-upgrades +prompt=normal +Then run +$ do-release-upgrade -d + +Or (least impact to your existing system) use a container. +You only use emulation, so you don't even need tricks to expose x86 HW acceleration for virtualization, just get a 20.10 system and work in there as you'd normally. +$ lxc launch ubuntu-daily:g g-20.10 +$ lxc exec g-20.10 + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1890152 b/results/classifier/108/other/1890152 new file mode 100644 index 000000000..8a62daa28 --- /dev/null +++ b/results/classifier/108/other/1890152 @@ -0,0 +1,73 @@ +other: 0.909 +performance: 0.795 +device: 0.779 +semantic: 0.765 +graphic: 0.740 +files: 0.720 +boot: 0.717 +debug: 0.707 +network: 0.692 +permissions: 0.665 +socket: 0.663 +PID: 0.662 +KVM: 0.648 +vnc: 0.559 + +malloc 0xff0000030 bytes with vmxnet3 + +Hello, +This reproducer causes vmxnet3 to malloc 0xff0000030 bytes + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001014 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +write 0x3e 0x1 0x05 +write 0x28 0x1 0xe1 +write 0x29 0x1 0xfe +write 0x2a 0x1 0xff +write 0x2b 0x1 0xff +write 0x2c 0x1 0xff +write 0x2d 0x1 0xff +write 0x2e 0x1 0xff +write 0x2f 0x1 0xff +write 0x31c 0x1 0xff +writeq 0xe0001020 0xef0bff5ecafe0000 +EOF + + + +================================================================= +==25727==ERROR: AddressSanitizer: allocator is out of memory trying to allocate 0xff0000030 bytes + #0 0x56476a43731d in malloc (/home/alxndr/Development/qemu/general-fuzz/build/i386-softmmu/qemu-system-i386+0x2bba31d) + #1 0x7fca345a8500 in g_malloc (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500) + #2 0x56476c616312 in vmxnet3_activate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1504:5 + #3 0x56476c6101ba in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1576:9 + #4 0x56476c60d30f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9 + #5 0x56476b11d383 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5 + #6 0x56476b11c827 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #7 0x56476b11a446 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16 + #8 0x56476a4cb696 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + #9 0x56476a4b3eb6 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + #10 0x56476a4b39d7 in address_space_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3308:18 + #11 0x56476b1c4614 in qtest_process_command /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:452:13 + #12 0x56476b1bbc18 in qtest_process_inbuf /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:710:9 + #13 0x56476b1ba8a5 in qtest_read /home/alxndr/Development/qemu/general-fuzz/softmmu/qtest.c:722:5 + #14 0x56476e063f03 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:188:9 + #15 0x56476e064087 in qemu_chr_be_write /home/alxndr/Development/qemu/general-fuzz/chardev/char.c:200:9 + #16 0x56476e078373 in fd_chr_read /home/alxndr/Development/qemu/general-fuzz/chardev/char-fd.c:68:9 + #17 0x56476e1cc734 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/general-fuzz/io/channel-watch.c:84:12 + #18 0x7fca345a2897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + + +-Alex + +Chronogically speaking #1913873 is a duplicate of #1890152... + diff --git a/results/classifier/108/other/1890155 b/results/classifier/108/other/1890155 new file mode 100644 index 000000000..b0838d1fd --- /dev/null +++ b/results/classifier/108/other/1890155 @@ -0,0 +1,64 @@ +graphic: 0.741 +device: 0.740 +permissions: 0.720 +debug: 0.653 +PID: 0.633 +semantic: 0.622 +vnc: 0.609 +network: 0.594 +KVM: 0.569 +other: 0.552 +boot: 0.550 +socket: 0.549 +files: 0.527 +performance: 0.495 + +Abort in vmxnet3_validate_interrupt_idx + +Hello, +Reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device vmxnet3 -m 64 -nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001014 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x80001018 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +write 0x0 0x1 0xe1 +write 0x1 0x1 0xfe +write 0x2 0x1 0xbe +write 0x3 0x1 0xba +write 0x52 0x1 0x61 +writeq 0xe0001020 0xef0bff5ecafe0000 +EOF + +============================================================== + #7 0x55b271a89b67 in hw_error /home/alxndr/Development/qemu/general-fuzz/softmmu/cpus.c:927:5 + #8 0x55b272fc6433 in vmxnet3_validate_interrupt_idx /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1355:9 + #9 0x55b272fc4e6d in vmxnet3_validate_interrupts /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1364:5 + #10 0x55b272fbe723 in vmxnet3_activate_device /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1546:5 + #11 0x55b272fb6fba in vmxnet3_handle_command /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1576:9 + #12 0x55b272fb410f in vmxnet3_io_bar1_write /home/alxndr/Development/qemu/general-fuzz/hw/net/vmxnet3.c:1772:9 + #13 0x55b271ac4193 in memory_region_write_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:483:5 + #14 0x55b271ac3637 in access_with_adjusted_size /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:544:18 + #15 0x55b271ac1256 in memory_region_dispatch_write /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:1466:16 + #16 0x55b270e724a6 in flatview_write_continue /home/alxndr/Development/qemu/general-fuzz/exec.c:3176:23 + #17 0x55b270e5acc6 in flatview_write /home/alxndr/Development/qemu/general-fuzz/exec.c:3216:14 + + +qemu: hardware error: Bad interrupt index: 97 +Aborted + +-Alex + +This still reproduces with the current version of QEMU. Marking as "Confirmed" + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/539 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/108/other/1890312 b/results/classifier/108/other/1890312 new file mode 100644 index 000000000..2faad2643 --- /dev/null +++ b/results/classifier/108/other/1890312 @@ -0,0 +1,86 @@ +permissions: 0.893 +graphic: 0.891 +semantic: 0.889 +other: 0.888 +device: 0.880 +performance: 0.869 +PID: 0.852 +debug: 0.841 +vnc: 0.787 +boot: 0.767 +files: 0.748 +KVM: 0.744 +socket: 0.696 +network: 0.682 + +Segfault in artist_vram_read + +Hello, +Reproducer: + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writew 0xf8118001 0x105a +readq 0xf900f8ff +EOF + +================================================================= +==20118==ERROR: AddressSanitizer: SEGV on unknown address 0x7fc6fb847672 (pc 0x55ec9c0f6828 bp 0x7ffd91000230 sp 0x7ffd90ffffd0 T0) +==20118==The signal is caused by a READ memory access. + #0 0x55ec9c0f6828 in artist_vram_read /hw/display/artist.c:1174:15 + #1 0x55ec9b84a582 in memory_region_read_accessor /softmmu/memory.c:434:11 + #2 0x55ec9b7d1adc in access_with_adjusted_size /softmmu/memory.c:539:18 + #3 0x55ec9b7cd769 in memory_region_dispatch_read1 /softmmu/memory.c:1385:16 + #4 0x55ec9b7cc855 in memory_region_dispatch_read /softmmu/memory.c:1414:9 + #5 0x55ec9ae621de in flatview_read_continue /exec.c:3239:23 + #6 0x55ec9ae64fb1 in flatview_read /exec.c:3279:12 + #7 0x55ec9ae64af7 in address_space_read_full /exec.c:3292:18 + #8 0x55ec9b87c990 in address_space_read /include/exec/memory.h:2429:18 + #9 0x55ec9b87c990 in qtest_process_command /softmmu/qtest.c:485:13 + #10 0x55ec9b870c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 + #11 0x55ec9b86f895 in qtest_read /softmmu/qtest.c:722:5 + #12 0x55ec9dd2b2f3 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #13 0x55ec9dd2b477 in qemu_chr_be_write /chardev/char.c:200:9 + #14 0x55ec9dd3f763 in fd_chr_read /chardev/char-fd.c:68:9 + #15 0x55ec9de93b24 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #16 0x7fc7261ad897 in g_main_context_dispatch () + #17 0x55ec9e28ba2b in glib_pollfds_poll /util/main-loop.c:217:9 + #18 0x55ec9e28915b in os_host_main_loop_wait /util/main-loop.c:240:5 + #19 0x55ec9e288af4 in main_loop_wait /util/main-loop.c:516:11 + #20 0x55ec9b891d00 in qemu_main_loop /softmmu/vl.c:1676:9 + #21 0x55ec9decb911 in main /softmmu/main.c:49:5 + +The error occurs even with Message-Id: <email address hidden> applied (I collected the above trace with the patch-set applied) + +Thanks +-Alex + +There's one more slightly further in the same function - line 1231 https://github.com/hdeller/qemu-hppa/blob/1e5391948f977932d17526c491d262a3cd99a690/hw/display/artist.c#L1231 + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writeq 0xf8118005 0x1e7c50ff016d65ff +readl 0xf9080100 +EOF + +[I 1596601465.827371] OPENED +[R +0.043473] writeq 0xf8118005 0x1e7c50ff016d65ff +18615@1596601465.870899:artist_reg_write 1 0x118005 DST_BM_ACCESS <- 0x1e +18615@1596601465.870911:artist_reg_write 2 0x118006 DST_BM_ACCESS <- 0x7c50 +18615@1596601465.870918:artist_reg_write 4 0x118008 SRC_BM_ACCESS <- 0xff016d65 +18615@1596601465.870924:artist_reg_write 1 0x11800c CONTROL_PLANE <- 0xff +OK +[S +0.043557] OK +[R +0.043574] readl 0xf9080100 +AddressSanitizer:DEADLYSIGNAL +================================================================= +==18615==ERROR: AddressSanitizer: SEGV on unknown address 0x7f12d2a01040 (pc 0x560323116048 bp 0x7fffa8723bf0 sp 0x7fffa8723990 T0) +==18615==The signal is caused by a READ memory access. + #0 0x560323116048 in artist_vram_read /home/alxndr/Development/qemu/general-fuzz/hw/display/artist.c:1231:23 + #1 0x560322868582 in memory_region_read_accessor /home/alxndr/Development/qemu/general-fuzz/softmmu/memory.c:434:11 +... + +Fixed in commit a501bfc91763d4642390090dd4e6039d67b63702. + +Released with QEMU v5.2.0. + diff --git a/results/classifier/108/other/1890333 b/results/classifier/108/other/1890333 new file mode 100644 index 000000000..1ea344057 --- /dev/null +++ b/results/classifier/108/other/1890333 @@ -0,0 +1,170 @@ +other: 0.888 +permissions: 0.876 +debug: 0.872 +performance: 0.868 +PID: 0.864 +graphic: 0.861 +device: 0.860 +semantic: 0.858 +network: 0.856 +boot: 0.846 +socket: 0.843 +files: 0.840 +KVM: 0.838 +vnc: 0.832 + +[OSS-Fuzz] Issue 26797: qemu:qemu-fuzz-i386-target-generic-fuzz-virtio-blk: ASSERT: addr < cache->len && 2 <= cache->len - addr + +Hello, +Reproducer: +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-device virtio-blk,drive=mydrive \ +-nodefaults -qtest stdio -nographic +outl 0xcf8 0x80001001 +outl 0xcfc 0x6574c1ff +outl 0xcf8 0x8000100e +outl 0xcfc 0xefe5e1e +outl 0xe86 0x3aff9090 +outl 0xe84 0x3aff9090 +outl 0xe8e 0xe +EOF + +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/include/exec/memory_ldst_cached.inc.h:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +Aborted + +I can trigger similar assertions with other VIRTIO devices, as-well. +I reported this at some point in Message-ID: <email address hidden> but never created a Launchpad issue... +-Alex + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26797 + +=== Reproducer (build with --enable-sanitizers) === +cat << EOF | ./qemu-system-i386 -display none \ +-machine accel=qtest, -m 512M -machine q35 \ +-device virtio-blk,drive=disk0 \ +-drive file=null-co://,id=disk0,if=none,format=raw \ +-qtest stdio +outl 0xcf8 0x80001889 +outl 0xcfc 0x1000ffff +outl 0xcf8 0x80001897 +outl 0xcf8 0x80001890 +outl 0xcfc 0x4 +outl 0xcf8 0x800018ff +outl 0xcf8 0x80001897 +inb 0xcfc +outl 0xcf8 0x8000188a +outl 0xcfc 0xd4624 +outl 0xcf8 0x80001897 +outl 0xcf8 0x80001806 +outl 0xcf8 0x80001897 +outl 0xcfc 0xff6ca0ba +outl 0xcf8 0x8000188c +outw 0xcfc 0x14 +outl 0xcf8 0x80001897 +outl 0xcf8 0x8000185a +outl 0xcf8 0x80001897 +outl 0xcfc 0x5f6c6346 +inb 0xcfc +outl 0xcf8 0x80001802 +outl 0xcfc 0x65a6055 +outl 0xcf8 0x80001897 +inb 0xcfc +outl 0xcf8 0x80001889 +outl 0xcfc 0x1869ffff +outl 0xcf8 0x80001812 +outl 0xcf8 0x80001897 +outl 0xcfc 0x5f6c6346 +outl 0xcf8 0x8000188c +outw 0xcfc 0x24 +outl 0xcf8 0x80001890 +outl 0xcf8 0x80001897 +outl 0xcfc 0x1 +outl 0xcf8 0x80001892 +outl 0xcfc 0x1ff04 +outl 0xcf8 0x8000188c +outw 0xcfc 0x1c +outl 0xcf8 0x80001890 +outl 0xcfc 0x1 +outl 0xcf8 0x80001897 +outl 0xcfc 0xfd467562 +outl 0xcf8 0x8000188a +outl 0xcfc 0x245a5546 +outl 0xcf8 0x80001890 +outl 0xcf8 0x80001897 +inb 0xcfc +outl 0xcf8 0x8000188c +outw 0xcfc 0x14 +outl 0xcf8 0x80001897 +outl 0xcf8 0x80001806 +outl 0xcf8 0x80001889 +outl 0xcfc 0x1869ffff +outl 0xcf8 0x80001812 +outl 0xcf8 0x80001897 +outl 0xcfc 0x6c6346 +outl 0xcf8 0x8000188c +outw 0xcfc 0x14 +outl 0xcf8 0x80001890 +outl 0xcf8 0x80001897 +outl 0xcfc 0x1ff04 +EOF + +=== Stack Trace === + +qemu-fuzz-i386-target-generic-fuzz-virtio-blk: /src/qemu/include/exec/memory_ldst_cached.h.inc:88: void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +==46== ERROR: libFuzzer: deadly signal +#0 0x55deb7b59e61 in __sanitizer_print_stack_trace /src/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3 +#1 0x55deb7aa1158 in fuzzer::PrintStackTrace() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:5 +#2 0x55deb7a87053 in fuzzer::Fuzzer::CrashCallback() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:233:3 +#3 0x7fccd310638f in libpthread.so.0 +#4 0x7fccd273e437 in gsignal +#5 0x7fccd2740039 in abort +#6 0x7fccd2736be6 in libc.so.6 +#7 0x7fccd2736c91 in __assert_fail +#8 0x55deb8416ba3 in address_space_stw_le_cached /src/qemu/include/exec/memory_ldst_cached.h.inc:88:5 +#9 0x55deb8416a40 in stw_le_phys_cached /src/qemu/include/exec/memory_ldst_phys.h.inc:121:5 +#10 0x55deb8416a13 in virtio_stw_phys_cached /src/qemu/include/hw/virtio/virtio-access.h:196:9 +#11 0x55deb8416899 in vring_set_avail_event /src/qemu/hw/virtio/virtio.c:428:5 +#12 0x55deb8406ba8 in virtio_queue_split_set_notification /src/qemu/hw/virtio/virtio.c:437:9 +#13 0x55deb84067a2 in virtio_queue_set_notification /src/qemu/hw/virtio/virtio.c:498:9 +#14 0x55deb84755d3 in virtio_blk_handle_vq /src/qemu/hw/block/virtio-blk.c:795:13 +#15 0x55deb84916ce in virtio_blk_data_plane_handle_output /src/qemu/hw/block/dataplane/virtio-blk.c:165:12 +#16 0x55deb841afaf in virtio_queue_notify_aio_vq /src/qemu/hw/virtio/virtio.c:2325:15 +#17 0x55deb8415adb in virtio_queue_host_notifier_aio_read /src/qemu/hw/virtio/virtio.c:3529:9 +#18 0x55deb892af84 in aio_dispatch_handler /src/qemu/util/aio-posix.c:329:9 +#19 0x55deb8929b8a in aio_dispatch_handlers /src/qemu/util/aio-posix.c:372:20 +#20 0x55deb8929ac0 in aio_dispatch /src/qemu/util/aio-posix.c:382:5 +#21 0x55deb893ae2c in aio_ctx_dispatch /src/qemu/util/async.c:306:5 +#22 0x7fccd3868196 in g_main_context_dispatch +#23 0x55deb8947fed in glib_pollfds_poll /src/qemu/util/main-loop.c:221:9 +#24 0x55deb8947264 in os_host_main_loop_wait /src/qemu/util/main-loop.c:244:5 +#25 0x55deb8946f25 in main_loop_wait /src/qemu/util/main-loop.c:520:11 +#26 0x55deb7b8806a in flush_events /src/qemu/tests/qtest/fuzz/fuzz.c:48:9 +#27 0x55deb7b85a32 in generic_fuzz /src/qemu/tests/qtest/fuzz/generic_fuzz.c:681:17 +#28 0x55deb7b88450 in LLVMFuzzerTestOneInput /src/qemu/tests/qtest/fuzz/fuzz.c:150:5 +#29 0x55deb7a887c1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:595:15 +#30 0x55deb7a73892 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6 +#31 0x55deb7a7994e in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:852:9 +#32 0x55deb7aa1932 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 +#33 0x7fccd272983f in __libc_start_main +#34 0x55deb7a4eb38 in _start + +Fix in commit 2d69eba5fe52045b2c8b0d04fd3806414352afc1 + +Hi, + +It seems while the minimized producer doesn't fail the assertion now, the original reproducer provided by OSS-Fuzz[1] can still crash the latest QEMU (1758428, Dec 12, built with --enable-sanitizers --enable-fuzzing). Could anyone check if they trigger different bugs? + +Tested on: + Ubuntu: 20.04.1 5.4.0-58-generic x86_64 + clang: 10.0.0-4ubuntu1 + glibc: 2.31-0ubuntu9.1 + libglib2.0-dev: 2.64.3-1~ubuntu20.04.1 + +[1] https://bugs.launchpad.net/qemu/+bug/1890333/comments/1 + + +There is a new bug that fails the same assertion, and maybe its minimized producer will help: + https://bugs.launchpad.net/qemu/+bug/1908062 + + diff --git a/results/classifier/108/other/1890370 b/results/classifier/108/other/1890370 new file mode 100644 index 000000000..adab6848c --- /dev/null +++ b/results/classifier/108/other/1890370 @@ -0,0 +1,90 @@ +other: 0.911 +graphic: 0.881 +performance: 0.837 +semantic: 0.827 +permissions: 0.827 +device: 0.781 +debug: 0.750 +files: 0.744 +PID: 0.742 +vnc: 0.726 +socket: 0.720 +network: 0.715 +boot: 0.646 +KVM: 0.548 + +Segfault in artist vram_bit_write + +Hello, +Reproducer: + +cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \ +-qtest stdio -accel qtest +writeq 0xf810049f 0xffffffffffffffff +writew 0xf8118001 0xff7c +writew 0xf8118000 0x8300 +writeq 0xf81005fb 0x5c18006400189e +EOF + + +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /hw/display/artist.c:402:17 in +AddressSanitizer:DEADLYSIGNAL +================================================================= +==23157==ERROR: AddressSanitizer: SEGV on unknown address 0x7f17563fffff (pc 0x560ce3ad742c bp 0x7ffe310c62e0 sp 0x7ffe310c5a60 T0) +==23157==The signal is caused by a WRITE memory access. + #0 0x560ce3ad742c in vram_bit_write /hw/display/artist.c:402:43 + #1 0x560ce3acf2ab in artist_reg_write /hw/display/artist.c:892:9 + #2 0x560ce31c37a3 in memory_region_write_accessor /softmmu/memory.c:483:5 + #3 0x560ce31c2adc in access_with_adjusted_size /softmmu/memory.c:539:18 + #4 0x560ce31c0873 in memory_region_dispatch_write /softmmu/memory.c:1466:16 + #5 0x560ce286e056 in flatview_write_continue /exec.c:3176:23 + #6 0x560ce2856866 in flatview_write /exec.c:3216:14 + #7 0x560ce2856387 in address_space_write /exec.c:3308:18 + #8 0x560ce326a604 in qtest_process_command /softmmu/qtest.c:452:13 + #9 0x560ce3261c08 in qtest_process_inbuf /softmmu/qtest.c:710:9 + #10 0x560ce3260895 in qtest_read /softmmu/qtest.c:722:5 + #11 0x560ce571d343 in qemu_chr_be_write_impl /chardev/char.c:188:9 + #12 0x560ce571d4c7 in qemu_chr_be_write /chardev/char.c:200:9 + #13 0x560ce57317b3 in fd_chr_read /chardev/char-fd.c:68:9 + #14 0x560ce5885b74 in qio_channel_fd_source_dispatch /io/channel-watch.c:84:12 + #15 0x7f1665259897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) + #16 0x560ce5c7da7b in glib_pollfds_poll /util/main-loop.c:217:9 + #17 0x560ce5c7b1ab in os_host_main_loop_wait /util/main-loop.c:240:5 + #18 0x560ce5c7ab44 in main_loop_wait /util/main-loop.c:516:11 + #19 0x560ce3282d00 in qemu_main_loop /softmmu/vl.c:1676:9 + #20 0x560ce58bd961 in main /softmmu/main.c:49:5 + #21 0x7f1663ddfe0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 + #22 0x560ce2761729 in _start (/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729) + + +With -trace artist\* + +[I 1596601002.853158] OPENED +[R +0.047035] writeq 0xf810049f 0xffffffffffffffff +24590@1596601002.900238:artist_reg_write 1 0x10049f <- 0xff +24590@1596601002.900258:artist_reg_write 4 0x1004a0 VRAM_IDX <- 0xffffffff +24590@1596601002.900269:artist_reg_write 2 0x1004a4 <- 0xffff +24590@1596601002.900280:artist_reg_write 1 0x1004a6 <- 0xff +OK +[S +0.047130] OK +[R +0.047159] writew 0xf8118001 0xff7c +24590@1596601002.900331:artist_reg_write 1 0x118001 CMAP_BM_ACCESS <- 0xff +24590@1596601002.900344:artist_reg_write 1 0x118002 CMAP_BM_ACCESS <- 0x7c +OK +[S +0.047194] OK +[R +0.047213] writew 0xf8118000 0x8300 +24590@1596601002.900383:artist_reg_write 2 0x118000 CMAP_BM_ACCESS <- 0x8300 +OK +[S +0.047231] OK +[R +0.047243] writeq 0xf81005fb 0x5c18006400189e +24590@1596601002.900410:artist_reg_write 1 0x1005fb <- 0x0 +24590@1596601002.900418:artist_reg_write 4 0x1005fc <- 0x5c180064 +24590@1596601002.900424:artist_reg_write 2 0x100600 VRAM_WRITE_INCR_X <- 0x18 +/home/alxndr/Development/qemu/general-fuzz/hw/display/artist.c:402:17: runtime error: store to misaligned address 0x7fd01d3fffff for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment +0x7fd01d3fffff: note: pointer points here +<memory cannot be printed> +SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/alxndr/Development/qemu/general-fuzz/hw/display/artist.c:402:17 in +AddressSanitizer:DEADLYSIGNAL + +-Alex + diff --git a/results/classifier/108/other/1890395 b/results/classifier/108/other/1890395 new file mode 100644 index 000000000..00a6309bc --- /dev/null +++ b/results/classifier/108/other/1890395 @@ -0,0 +1,184 @@ +other: 0.933 +graphic: 0.925 +permissions: 0.907 +semantic: 0.887 +device: 0.883 +performance: 0.883 +debug: 0.833 +KVM: 0.823 +PID: 0.818 +boot: 0.817 +socket: 0.814 +files: 0.809 +network: 0.786 +vnc: 0.739 + +qmp/hmp: crash if client closes socket too early + +Qemu crashes on qmp/hmp command if client closes connection before reading the whole response from the socket. + +Reproducer: + +1. Start arbitrary vm via qemu +2. Send e.g. hmp command 'info mem' +3. Abort before whole response came back + + +Stack Trace: + +Stack trace of thread 6493: +#0 0x0000559902fd2d30 object_get_class (qemu-system-x86_64) +#1 0x0000559903071020 qio_channel_create_watch (qemu-system-x86_64) +#2 0x000055990305f437 qemu_chr_fe_add_watch (qemu-system-x86_64) +#3 0x0000559902f7340d monitor_flush_locked (qemu-system-x86_64) +#4 0x0000559902f7360e monitor_flush_locked (qemu-system-x86_64) +#5 0x0000559902f74342 qmp_send_response (qemu-system-x86_64) +#6 0x0000559902f74409 monitor_qmp_respond (qemu-system-x86_64) +#7 0x0000559902f74bc0 monitor_qmp_bh_dispatcher (qemu-system-x86_64) +#8 0x00005599030c37be aio_bh_call (qemu-system-x86_64) +#9 0x00005599030c6dd0 aio_dispatch (qemu-system-x86_64) +#10 0x00005599030c369e aio_ctx_dispatch (qemu-system-x86_64) +#11 0x00007f5b6d37f417 g_main_context_dispatch (libglib-2.0.so.0) +#12 0x00005599030c5e0a glib_pollfds_poll (qemu-system-x86_64) +#13 0x0000559902dd75df main_loop (qemu-system-x86_64) +#14 0x0000559902c59f49 main (qemu-system-x86_64) +#15 0x00007f5b6bfeab97 __libc_start_main (libc.so.6) +#16 0x0000559902c5d38a _start (qemu-system-x86_64) + +#0 0x0000559902fd2d30 in object_get_class (obj=obj@entry=0x0) at ./qom/object.c:909 +#1 0x0000559903071020 in qio_channel_create_watch (ioc=0x0, condition=(G_IO_OUT | G_IO_HUP)) at ./io/channel.c:281 + klass = <optimized out> + __func__ = "qio_channel_create_watch" + ret = <optimized out> +#2 0x000055990305f437 in qemu_chr_fe_add_watch (be=be@entry=0x559905a7f460, cond=cond@entry=(G_IO_OUT | G_IO_HUP), func=func@entry=0x559902f734b0 <monitor_unblocked>, user_data=user_data@entry=0x559905a7f460) at ./chardev/char-fe.c:367 + s = 0x5599055782c0 + src = <optimized out> + tag = <optimized out> + __func__ = "qemu_chr_fe_add_watch" +#3 0x0000559902f7340d in monitor_flush_locked (mon=mon@entry=0x559905a7f460) at ./monitor/monitor.c:140 + rc = 219264 + len = 3865832 + buf = 0x7f5afc00e480 "{\"return\": \"ffff9eb480000000-ffff9eb480099000 ", '0' <repeats 11 times>, "99000 -rw\\r\\nffff9eb480099000-ffff9eb48009b000 ", '0' <repeats 12 times>, "2000 -r-\\r\\nffff9eb48009b000-ffff9eb486800000 0000000006765000 -rw\\r\\nffff9eb4868000"... +#4 0x0000559902f7360e in monitor_flush_locked (mon=0x559905a7f460) at ./monitor/monitor.c:160 + i = 3865830 + c = <optimized out> +#5 0x0000559902f7360e in monitor_puts (mon=mon@entry=0x559905a7f460, str=0x7f5aa1eda010 "{\"return\": \"ffff9eb480000000-ffff9eb480099000 ", '0' <repeats 11 times>, "99000 -rw\\r\\nffff9eb480099000-ffff9eb48009b000 ", '0' <repeats 12 times>, "2000 -r-\\r\\nffff9eb48009b000-ffff9eb486800000 0000000006765000 -rw\\r\\nffff9eb4868000"...) at ./monitor/monitor.c:167 + i = 3865830 + c = <optimized out> +#6 0x0000559902f74342 in qmp_send_response (mon=0x559905a7f460, rsp=<optimized out>) at ./monitor/qmp.c:119 + data = <optimized out> + json = 0x559906c88380 +#7 0x0000559902f74409 in monitor_qmp_respond (rsp=0x559905bbf740, mon=0x559905a7f460) at ./monitor/qmp.c:132 + old_mon = <optimized out> + rsp = 0x559905bbf740 + error = <optimized out> +#8 0x0000559902f74409 in monitor_qmp_dispatch (mon=0x559905a7f460, req=<optimized out>) at ./monitor/qmp.c:161 + old_mon = <optimized out> + rsp = 0x559905bbf740 + error = <optimized out> +#9 0x0000559902f74bc0 in monitor_qmp_bh_dispatcher (data=<optimized out>) at ./monitor/qmp.c:234 + id = <optimized out> + rsp = <optimized out> + need_resume = true + mon = 0x559905a7f460 + __PRETTY_FUNCTION__ = "monitor_qmp_bh_dispatcher" +#10 0x00005599030c37be in aio_bh_call (bh=0x559905571b40) at ./util/async.c:89 + bh = 0x559905571b40 + bhp = <optimized out> + next = 0x5599055718f0 + ret = 1 + deleted = false +#11 0x00005599030c37be in aio_bh_poll (ctx=ctx@entry=0x5599055706f0) at ./util/async.c:117 + bh = 0x559905571b40 + bhp = <optimized out> + next = 0x5599055718f0 + ret = 1 + deleted = false +#12 0x00005599030c6dd0 in aio_dispatch (ctx=0x5599055706f0) at ./util/aio-posix.c:459 +#13 0x00005599030c369e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ./util/async.c:260 + ctx = <optimized out> +#14 0x00007f5b6d37f417 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 +#15 0x00005599030c5e0a in glib_pollfds_poll () at ./util/main-loop.c:219 + context = 0x559905652420 + pfds = <optimized out> + context = 0x559905652420 + ret = 1 + mlpoll = {state = 0, timeout = 4294967295, pollfds = 0x559905651800} +#16 0x00005599030c5e0a in os_host_main_loop_wait (timeout=14451267) at ./util/main-loop.c:242 + context = 0x559905652420 + ret = 1 + mlpoll = {state = 0, timeout = 4294967295, pollfds = 0x559905651800} +#17 0x00005599030c5e0a in main_loop_wait (nonblocking=<optimized out>) at ./util/main-loop.c:518 + mlpoll = {state = 0, timeout = 4294967295, pollfds = 0x559905651800} +#18 0x0000559902dd75df in main_loop () at ./vl.c:1810 +#19 0x0000559902c59f49 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ./vl.c:4466 + i = <optimized out> + snapshot = 0 + linux_boot = <optimized out> + initrd_filename = 0x0 + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = 0x55990318bc94 "cad" + boot_once = <optimized out> + ds = <optimized out> + opts = <optimized out> + icount_opts = <optimized out> + accel_opts = 0x0 + olist = <optimized out> + optind = 100 + optarg = 0x7ffe0ca05e74 "timestamp=on" + loadvm = 0x0 + cpu_option = 0x7ffe0ca05d42 "SandyBridge-IBRS,-kvm_steal_time,+pcid,+ssbd,+spec-ctrl,+md-clear" + vga_model = 0x0 + qtest_chrdev = 0x0 + qtest_log = 0x0 + incoming = 0x0 + userconfig = <optimized out> + nographic = false + display_remote = <optimized out> + log_mask = <optimized out> + log_file = 0x0 + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = 0 + vmstate_dump_file = 0x0 + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = false + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffe0ca03540} + plugin_list = {tqh_first = 0x0, tqh_circ = {tql_next = 0x0, tql_prev = 0x7ffe0ca03550}} + __func__ = "main" + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1890545 b/results/classifier/108/other/1890545 new file mode 100644 index 000000000..481bde087 --- /dev/null +++ b/results/classifier/108/other/1890545 @@ -0,0 +1,407 @@ +other: 0.958 +permissions: 0.951 +graphic: 0.942 +debug: 0.937 +device: 0.932 +semantic: 0.932 +PID: 0.928 +performance: 0.906 +vnc: 0.878 +files: 0.862 +boot: 0.852 +KVM: 0.819 +network: 0.818 +socket: 0.743 + +(ARM64) qemu-x86_64+schroot(Debian bullseye) can't run chrome and can't load HTML + +First I creat a file system that is debian(bullseye amd64)on arm64 machine，then I download google-chrome，however, when I ran Google browser, some errors occurred. + +$ google-chrome --no-sandbox +or +$ qemu-x86_64-static google-chrome --no-sandbox + +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +[1661:1661:0806/074307.502638:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes) +[1664:1664:0806/074307.504159:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes) +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +[1637:1678:0806/074308.337567:ERROR:file_path_watcher_linux.cc(315)] inotify_init() failed: Function not implemented (38) +Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank" +qemu: unknown option 'type=utility' +[1637:1680:0806/074313.598432:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye. +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +Trace/breakpoint trap + +Why? +And then I run firefox,it can be opened, but it can't load any web pages and HTML. +I really need help！ +Thank. + +Hi + +When I run some app,like google-chrome: + + qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped + + + + + + +Which QEMU version are you using ? + + +Hi Peter,I use 5.1.0-rc3. + +It's fine on x86 that I use qemu-x86_64-static.But it's bad on arm.So what is the problem? + + + +Tony.LI <email address hidden> writes: + +> It's fine on x86 that I use qemu-x86_64-static.But it's bad on arm.So +> what is the problem? + +Could be a number of things - is Chrome using threading alongside it's +multiple processes? + +-- +Alex Bennée + + +Hi,Alex.May be you are right.I don't understand what you want to express. +I don't know what causes traps. +Is it caused by software, or qemu executes CPU-sensitive instruction simulation. + + + +Tony.LI <email address hidden> writes: + +> Hi,Alex.May be you are right.I don't understand what you want to express. +> I don't know what causes traps. +> Is it caused by software, or qemu executes CPU-sensitive instruction simulation. + +Does it work if you run: + + taskset 1 qemu-x86_64 google-chrome + +-- +Alex Bennée + + +Hi,Alex.It can't work.And I find some thing: + +$ glxinfo | grep -i open + +radeon: Failed to get PCI ID, error number -38 +libGL error: failed to create dri screen +libGL error: failed to load driver: radeonsi +libGL error: failed to get magic +libGL error: failed to load driver: radeonsi +OpenGL vendor string: VMware, Inc. +OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.9, 128 bits) +OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.6 +OpenGL core profile shading language version string: 3.30 +OpenGL core profile context flags: (none) +OpenGL core profile profile mask: core profile +OpenGL core profile extensions: +OpenGL version string: 3.0 Mesa 13.0.6 +OpenGL shading language version string: 1.30 +OpenGL context flags: (none) +OpenGL extensions: +OpenGL ES profile version string: OpenGL ES 3.0 Mesa 13.0.6 +OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 +OpenGL ES profile extensions: + +So，could it be a problem with the PCI? I see a lot of questions about PCI when use qemu-system.But，what should I do?And I use qemu-user like qemu-x86_64-static. + +$ lspci +00:00.0 PCI bridge: Cadence Design Systems, Inc. Device dc16 +00:01.0 PCI bridge: Cadence Design Systems, Inc. Device dc08 +00:02.0 PCI bridge: Cadence Design Systems, Inc. Device dc01 +00:03.0 PCI bridge: Cadence Design Systems, Inc. Device dc16 +00:04.0 PCI bridge: Cadence Design Systems, Inc. Device dc08 +00:05.0 PCI bridge: Cadence Design Systems, Inc. Device dc01 +02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 / Radeon 520 OEM] (rev 87) +02:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000 Series] +03:00.0 SATA controller: Marvell Technology Group Ltd. Device 9215 (rev 11) +06:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03) + +Outside chroot,I get the same infomation! +Why? "radeon: Failed to get PCI ID, error number -38" + + +And I can get some infomation by "qemu-x86_64-static -d strace". + +.... +17344 getdents(8,274880624768,32768,115,274880624899,39) = 0 +17344 close(8) = 0 +17344 ioctl(7,0xc0406400,0x297330) = 0 +17344 ioctl(7,0xc0406400,0x297330) = 0 +17344 fstat(7,0x0000004001a0b660) = 0 +17344 fcntl(7,F_DUPFD_CLOEXEC,3) = 8 +17344 ioctl(8,0xc0406400,0x297330) = 0 +17344 ioctl(8,0xc0406400,0x297330) = 0 +17344 ioctl(8,0xc0106467,0x1a0b700) = -1 errno=38 (Function not implemented) +.... + +Last ioctl is error,why?It drives me crazy!!! + +ioctl number 0xc0106467 is DRM_IOCTL_RADEON_INFO. QEMU doesn't support that ioctl (each ioctl needs individual handling to convert the data structures it uses between the guest and host architecture). If your guest binary is trying to make graphics-card specific ioctl calls like this then I'm afraid it won't work in QEMU (unless somebody writes the QEMU patch to make it support them). + + +Hi,Peter. +I have added the ioctl() patch for Radeon driver in Qemu. +However, there are many ioctls that only give cmd, I don't know where it comes from. + +12161 poll(275275025312,1,4294967295,1,0,67108865) +12161 futex(0x000000400002f898,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 0 +12161 memfd_create(275207539749,3,100,24,0,7883677795399066671) = 12 +12161 ftruncate(12,4,100,180,0,7883677795399066671) = 0 +12161 mmap(NULL,4,PROT_READ|PROT_WRITE,MAP_SHARED,12,0) = 0x0000004027f4b000 +12161 clock_gettime(1,274903098336,0,4,274878804488,274878804096) = 0 +12161 ioctl(11,0xc020645d,0x18063f0) = 0 +12161 ioctl(11,0xc018646b,0x18063d0) = 0 +12161 ioctl(11,0xc00c6468,0x18077ac) = 0 +12161 ioctl(11,0xc00c642d,0x1807750) = -1 errno=38 (Function not implemented) +12161 ioctl(11,0xc018646b,0x1807880) = 0 +12161 ioctl(11,0x40086409,0x1807878) = -1 errno=38 (Function not implemented) + +What device is 0xc00c642d??And more... +What should I do ? Can anyone give me some suggestions? + +Hi,I have already added ioctl(), but there is one individual issue. + +Like this: +ioctl(54, _IOC(_IOC_READ, 0xf5, 0x0c, 0x04) <unfinished ...> + +But,despite the appearance: + +15461 open("/home/tony/.config/google-chrome/Default/Web Data",O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC,0600) = 43 +15461 clock_gettime(1,275070715216,0,16,547700673376,4) = 0 +15461 fstat(43,0x0000004025148d50) = 0 +15461 fstat(43,0x00000040251489a0) = 0 +15461 stat("/home/greatwall/.config/google-chrome/Default/Web Data",0x0000004025148910) = 0 +15461 ioctl(43,0x8004f50c,0x25148fc4) = -1 errno=25 (Inappropriate ioctl for device) +15461 pread64(43,275500011632,100,0,0,274910104856)15461 gettimeofday(275070717920,275070717904,1,547702733952,0,275070717328) = 0 + = 100 + +Why is there such an error(Inappropriate ioctl for device)?? + + + +Hi,I added a patch for ioctl(), and in the system call, I found no other errors, but it still doesn't work.And，I use the "qemu-x86_64 -d unimp xxx" command,I found this error: + + Unknown QEMU_IFLA_INFO_KIND sit + +In the Qemu source code: +linux-user/fd-trans.c +.... + /* nested */ + case QEMU_IFLA_INFO_DATA: + if (strncmp(li_context->name, "bridge", + li_context->len) == 0) { + return host_to_target_for_each_nlattr(NLA_DATA(nlattr), + nlattr->nla_len, + NULL, + host_to_target_data_bridge_nlattr); + } else if (strncmp(li_context->name, "tun", + li_context->len) == 0) { + return host_to_target_for_each_nlattr(NLA_DATA(nlattr), + nlattr->nla_len, + NULL, + host_to_target_data_tun_nlattr); + } else { + qemu_log_mask(LOG_UNIMP, "Unknown QEMU_IFLA_INFO_KIND %s\n", + li_context->name); + } + break; + +.... + +What does it mean? +And how can i solve it? +Thank you!!! + +Could you try attached patch? + +Hi,I have add QEMU_IFLA_INFO_KIND nested type for sit.But I still can't open Google browser. +And there are still the following errors: + +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +[1661:1661:0806/074307.502638:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes) +[1664:1664:0806/074307.504159:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes) +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +qemu: unknown option 'type=utility' +[1637:1680:0806/074313.598432:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye. +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +Trace/breakpoint trap + +Qemu get the signal(INT3). +What causes this signal??? + +I don't know how to debug. When I block the operation of int3 in QEMU, it has the following error: + +qemu: 0x4004bc7855: unhandled CPU exception 0x3 - aborting +RAX=953ad79643deb400 RBX=0000007fa1203140 RCX=953ad79643deb400 RDX=000000400863f1d8 +RSI=0000004000b33f18 RDI=000000000000000e RBP=000000400863f590 RSP=000000400863f3c0 +R8 =0000000000000000 R9 =0000000000000001 R10=0000000000000000 R11=000000400aa153c0 +R12=000000400863f5a0 R13=0000000000000000 R14=0000007fa1218e10 R15=000000400863f5a0 +RIP=0000004004bc7855 RFL=00000246 [---Z-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 +ES =0000 0000000000000000 00000000 00000000 +CS =0033 0000000000000000 ffffffff 00effb00 DPL=3 CS64 [-RA] +SS =002b 0000000000000000 ffffffff 00cff300 DPL=3 DS [-WA] +DS =0000 0000000000000000 00000000 00000000 +FS =0000 000000400c0c3840 00000000 00000000 +GS =0000 0000000000000000 00000000 00000000 +LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT +TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy +GDT= 000000400866f000 0000007f +IDT= 000000400866e000 F000001ff +CR0=80010001 CR2=0000000000000000 CR3=0000000000000000 CR4=00000220 +DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 +DR6=00000000ffff0ff0 DR7=0000000000000400 +EFER=0000000000000500 + +Is it possible that the CPU of arm does not support certain instructions?But，I don't know. +Who can give me some advice? +Thank you！ + + +I wrote an example to load local HTML: + +#include "mainwindow.h" +#include "ui_mainwindow.h" +#include <QWebEngineView> +MainWindow::MainWindow(QWidget *parent) : + QMainWindow(parent), + ui(new Ui::MainWindow) +{ + ui->setupUi(this); + + QWebEngineView *webView = new QWebEngineView(this); + + webView->load(QUrl("file:////home/tony/1.html")); + webView->setFixedSize(this->width(),this->height()); + webView->show(); +} + +MainWindow::~MainWindow() +{ + delete ui; +} + + +At the same time, I found that a process(QtWebEngineProcess) did not start properly; +Then,I run: + + $ ./QtWebEngineProcess --type=zygote --webengine-schemes=qrc:sLV --lang=zh + qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped + + But,I didn't find any mistakes.Why does the process exit? + + + + +I wrote an example to load local HTML: + +#include "mainwindow.h" +#include "ui_mainwindow.h" +#include <QWebEngineView> +MainWindow::MainWindow(QWidget *parent) : + QMainWindow(parent), + ui(new Ui::MainWindow) +{ + ui->setupUi(this); + + QWebEngineView *webView = new QWebEngineView(this); + + webView->load(QUrl("file:////home/tony/1.html")); + webView->setFixedSize(this->width(),this->height()); + webView->show(); +} + +MainWindow::~MainWindow() +{ + delete ui; +} + +At the same time, I found that a process(QtWebEngineProcess) did not start properly; +Then,I run: + + $ ./QtWebEngineProcess --type=zygote --webengine-schemes=qrc:sLV + qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped + + But,I didn't find any mistakes.Why does the process exit? + + +Now, I found something new when I use gdb: + +=> 0x400523c858: ud2 + 0x400523c85a: pushq $0xd + 0x400523c85c: mov -0x230(%rbp),%rax + 0x400523c863: mov -0x240(%rbp),%rdi + 0x400523c86a: mov $0x1,%esi + 0x400523c86f: movq $0x0,-0x230(%rbp) + 0x400523c87a: mov %rax,-0x220(%rbp) + 0x400523c881: callq 0x40051ccf00 + 0x400523c886: callq 0x400266c540 + 0x400523c88b: cmp $0x1,%eax + 0x400523c88e: je 0x400523c8ed + 0x400523c890: lea -0x220(%rbp),%rdi + 0x400523c897: callq 0x40040fe8e0 + 0x400523c89c: jmpq 0x400523c60c + 0x400523c8a1: int3 + 0x400523c8a2: ud2 + 0x400523c8a4: pushq $0x10 + 0x400523c8a6: int3 + 0x400523c8a7: ud2 + 0x400523c8a9: pushq $0x11 + 0x400523c8ab: mov -0x200(%rbp),%rax + 0x400523c8b2: lea -0x1c0(%rbp),%rbx + 0x400523c8b9: movq $0x0,-0x200(%rbp) + +This is where the error occurred: +(gdb) x/30i 0x40007ff2c0 + 0x40007ff2c0: xor %al,%dh + 0x40007ff2c2: (bad) + 0x40007ff2c3: add %al,(%rax) + 0x40007ff2c5: add %al,(%rax) + 0x40007ff2c7: add %ch,0x0(%rbp) + 0x40007ff2cd: add %al,(%rax) + 0x40007ff2cf: add %dl,0x62d7(%rax) + 0x40007ff2d5: add %al,(%rax) + 0x40007ff2d7: add %cl,-0x16(%rdx) + 0x40007ff2da: test %ecx,(%rdx) + 0x40007ff2dc: add %al,(%rax) + 0x40007ff2df: add %al,(%rcx) + 0x40007ff2e1: repz jg 0x40007ff2e4 + 0x40007ff2e4: add %al,(%rax) + 0x40007ff2e7: add %bl,-0xd(%rax) + 0x40007ff2ea: jg 0x40007ff2ec + 0x40007ff2ec: add %al,(%rax) + 0x40007ff2ef: add %bl,-0xd(%rax) + 0x40007ff2f2: jg 0x40007ff2f4 + 0x40007ff2f4: add %al,(%rax) + 0x40007ff2f7: add %dh,(%rax) + 0x40007ff2f9: repz jg 0x40007ff2fc + 0x40007ff2fc: add %al,(%rax) + +(bad)?? What's it mean? + +I found out the reason for "qemu: unknown option 'type=utility'", created a sample code to demo it and a small wrokaround patch to chromium. Found more info in: +https://bugs.launchpad.net/qemu/+bug/1926246 + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/280 + + diff --git a/results/classifier/108/other/1890775 b/results/classifier/108/other/1890775 new file mode 100644 index 000000000..46372a969 --- /dev/null +++ b/results/classifier/108/other/1890775 @@ -0,0 +1,72 @@ +files: 0.874 +performance: 0.852 +device: 0.820 +graphic: 0.818 +other: 0.749 +semantic: 0.693 +network: 0.658 +permissions: 0.618 +socket: 0.573 +vnc: 0.535 +debug: 0.528 +PID: 0.431 +boot: 0.348 +KVM: 0.316 + +Aten USB to Serial bridge does not work with qemu under Windows 10 + +I would like to use MSDOS 6.22 with qemu (unfortunatelly lot of our test programs has been written in dos). +I tried to connect two laptop by RS232 port, one of the machine have a built-in serial port and run with native MSDOS 6.22 with 4.0 norton commander. Another machine have only USB ports and i try to use a new Aten USB to Serial device. Ok. Has been started qemu with -serial and -chardev parameters, at startup appear a window with serial port setting such as baud rate, start bit, etc... + +Quemu has been satrted succeeded but serial port cannot be used becouse was nothing activited on usb serial adapter :( + +I tried same configuration with VirtualBox and everything was worked fine (serial connection was estabiled and copied several files from one machine into another machine), seems to be the emulated serial port has been worked fine. + +I would like to use qemu, i just thougt qemu is better, simple and faster... + +Exists solution or is this a qemu bug? + +Thank you! + +I forgot that the environment is Windows 10 64 bit. + +Hi again, + +Seems to be there is no solution for my problem :( +I have succeeded create NTVDMx64 patch on my Windows 10 installation, so i can run directly 16 bit ms dos applications without any dos emulator. +I take the initiative to close the bug. + +Bye + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + |