1 files changed, 102 insertions, 0 deletions
diff --git a/results/classifier/118/none/1849894 b/results/classifier/118/none/1849894
new file mode 100644
index 000000000..70fe633b4
--- /dev/null
+++ b/results/classifier/118/none/1849894
@@ -0,0 +1,102 @@
+user-level: 0.534
+TCG: 0.514
+VMM: 0.466
+peripherals: 0.451
+hypervisor: 0.412
+arm: 0.409
+ppc: 0.407
+x86: 0.403
+mistranslation: 0.390
+virtual: 0.383
+i386: 0.378
+architecture: 0.376
+permissions: 0.374
+KVM: 0.371
+PID: 0.363
+device: 0.344
+vnc: 0.343
+performance: 0.338
+socket: 0.336
+register: 0.334
+network: 0.331
+semantic: 0.329
+graphic: 0.327
+kernel: 0.323
+files: 0.321
+risc-v: 0.319
+debug: 0.296
+assembly: 0.285
+boot: 0.285
+
+hw/scsi/scsi-disk.c line 2554 allocation overflow
+
+When compiling qemu from git master (at commit 03bf012e523ecdf047ac56b2057950247256064d ) on Linux amd64, with gcc-9 9.2.1 , and using `-march=native -flto`, during linking of most target binaries, compiler does detect an issue with allocation in scsi_disk_new_request_dump and aborts compilation.
+
+
+make[1]: Entering directory '/home/user/qemu/slirp'
+make[1]: Nothing to be done for 'all'.
+make[1]: Leaving directory '/home/user/qemu/slirp'
+nm: stats64.o: no symbols
+  LINK    aarch64-softmmu/qemu-system-aarch64
+In function ‘scsi_disk_new_request_dump’,
+    inlined from ‘scsi_new_request’ at hw/scsi/scsi-disk.c:2580:9,
+    inlined from ‘scsi_new_request’ at hw/scsi/scsi-disk.c:2564:21:
+hw/scsi/scsi-disk.c:2554:19: error: argument 1 value ‘18446744073709551612’ exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
+hw/scsi/scsi-disk.c: In function ‘scsi_new_request’:
+/usr/include/glib-2.0/glib/gmem.h:78:10: note: in a call to allocation function ‘g_malloc’ declared here
+   78 | gpointer g_malloc         (gsize  n_bytes) G_GNUC_MALLOC G_GNUC_ALLOC_SIZE(1);
+      |          ^
+lto1: all warnings being treated as errors
+lto-wrapper: fatal error: c++ returned 1 exit status
+compilation terminated.
+/usr/bin/ld: error: lto-wrapper failed
+collect2: error: ld returned 1 exit status
+
+
+
+same happens for most other targets: alpha-softmmu/qemu-system-alpha arm-softmmu/qemu-system-arm hppa-softmmu/qemu-system-hppa i386-softmmu/qemu-system-i386 lm32-softmmu/qemu-system-lm32 mips-softmmu/qemu-system-mips mips64-softmmu/qemu-system-mips64 mips64el-softmmu/qemu-system-mips64el mipsel-softmmu/qemu-system-mipsel ppc-softmmu/qemu-system-ppc ppc64-softmmu/qemu-system-ppc64 riscv32-softmmu/qemu-system-riscv32 riscv64-softmmu/qemu-system-riscv64 s390x-softmmu/qemu-system-s390x sh4-softmmu/qemu-system-sh4 sh4eb-softmmu/qemu-system-sh4eb sparc-softmmu/qemu-system-sparc sparc64-softmmu/qemu-system-sparc64 x86_64-softmmu/qemu-system-x86_64 xtensa-softmmu/qemu-system-xtensa xtensaeb-softmmu/qemu-system-xtensaeb
+
+Notice -softmmu being a common factor here.
+
+
+
+The size of the allocation for the temporary buffer for dumping using snprintf is determined based on the size of the buffer via call to scsi_cdb_length. I believe the heavy inlining and constant propagation makes scsi_cdb_length return -1, so len = -1. Then allocation size is 5*len + 1, or -4. Which overflows to 2^64 - 4 or so.
+
+The case of len==-1 from scsi_cdb_length happens if the (buf[0] >> 5) is not 0, 1, 2, 4 or 5.
+
+However, I can't find out how gcc figures out that buf[0] is not one of these variables. To me looking at this function, compiler should not know anything about buf[0].
+
+I tried following the chain of calls back, including devirtualize alloc_req, and I found scsi_device_alloc_req calling these alloc_req callbacks, but it is itself called from scsi_req_new, which is called in  get_scsi_requests , just after buf is filled from QEMUFile using qemu_get_buffer, which ultimately goes even further into read paths, which there might be many AFAIK.
+
+
+
+
+glib2 version 2.62.1-1
+
+FYI. Adding if (len <= 0) return; in the scsi_disk_new_request_dump solved the compilation issue for me.
+
+So indeed gcc thinks len == -1
+
+I am pretty sure the build qemu is functional, as this path is only taken if the trace_event_get_state_backends(TRACE_SCSI_DISK_NEW_REQUEST) is true, which by default it is not.
+
+BTW. Also, aarch64-softmmu/qemu-system-aarch64 takes very long time to link compared to other targets, so I recommend using -flto=16 to increase parallelism, and reduce lto link time to about 4 minutes. (But 64GB of memory recommended).
+
+I also tested with --disable-slirp configure flag. Still same issue.
+
+The QEMU project is currently considering to move 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 older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+Likely not happening anymore since commit e91bae8e98a ("scsi: Silence gcc warning").
+
+[Expired for QEMU because there has been no activity for 60 days.]
+