diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1876 | 16 | ||||
| -rw-r--r-- | results/classifier/108/other/1876187 | 29 | ||||
| -rw-r--r-- | results/classifier/108/other/1876373 | 91 | ||||
| -rw-r--r-- | results/classifier/108/other/1876568 | 47 |
4 files changed, 183 insertions, 0 deletions
diff --git a/results/classifier/108/other/1876 b/results/classifier/108/other/1876 new file mode 100644 index 00000000..1209cb38 --- /dev/null +++ b/results/classifier/108/other/1876 @@ -0,0 +1,16 @@ +network: 0.813 +performance: 0.710 +device: 0.605 +debug: 0.531 +semantic: 0.301 +graphic: 0.290 +other: 0.270 +permissions: 0.139 +PID: 0.081 +vnc: 0.081 +boot: 0.077 +socket: 0.066 +files: 0.027 +KVM: 0.008 + +Host wayland gtk problem diff --git a/results/classifier/108/other/1876187 b/results/classifier/108/other/1876187 new file mode 100644 index 00000000..dda4b152 --- /dev/null +++ b/results/classifier/108/other/1876187 @@ -0,0 +1,29 @@ +network: 0.748 +performance: 0.734 +device: 0.719 +files: 0.657 +vnc: 0.622 +PID: 0.618 +socket: 0.582 +graphic: 0.568 +permissions: 0.542 +semantic: 0.451 +other: 0.357 +boot: 0.336 +debug: 0.261 +KVM: 0.047 + +qemu-system-arm freezes when using SystickTimer on netduinoplus2 + +git commit 27c94566379069fb8930bb1433dcffbf7df3203d + +The global variable system_clock_scale used in hw/timer/armv7m_systick.c is never set on the netduinoplus2 platform, it stays initialized as zero. Using the timer with the clock source as cpu clock leads to an infinit loop because systick_timer->tick always stays the same. + +To reproduce use to CMSIS function SysTick_Config(uint32_t ticks) to setup the timer. + +Patch sent to list: https://<email address hidden>/ + + +Patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e7e5a9595ab1136845c + diff --git a/results/classifier/108/other/1876373 b/results/classifier/108/other/1876373 new file mode 100644 index 00000000..13f833dc --- /dev/null +++ b/results/classifier/108/other/1876373 @@ -0,0 +1,91 @@ +debug: 0.895 +permissions: 0.861 +device: 0.842 +graphic: 0.829 +performance: 0.829 +PID: 0.821 +other: 0.818 +semantic: 0.785 +vnc: 0.774 +files: 0.747 +network: 0.726 +boot: 0.710 +socket: 0.677 +KVM: 0.640 + +segfault mremap 4096 + +a qemu-hosted process segfaults when the program calls mremap to shrink the size of a buffer to 4096 that was allocated with mmap. See below for a C program to reproduce this issue. I was able to compile this program for both i386 and 32-bit arm, and use qemu-i386 and qemu-arm to reproduce the segfault. If I run the i386 program natively on my x86_64 system, no segfault occurs. Also note that if I change the mremap size to something else such as 12288, no segfault occurs. I also confirmed using qemu's -singlestep debug option that the segfault occurs during the mremap syscall. + +If you save the source below to mremapbug.c, the following should reproduce the issue given you have gcc-multilib: + +gcc -m32 mremapbug.c +# works +./a.out +# segfault +qemu-i386 a.out + +If you can also compile to arm, the same thing happens when running "qemu-arm a.out". I also tried compiling natively and running "qemu-x86_64 a.out" but no segfault in that case, not sure if it's because it is 64-bits or if it was because it was my native target. + + +#define _GNU_SOURCE +#include <stdlib.h> +#include <stdio.h> +#include <sys/mman.h> + +int main(int argc, char *argv[]) +{ + const size_t initial_size = 8192; + + printf("calling mmap, size=%llu\n", (unsigned long long)initial_size); + void *mmap_ptr = mmap(NULL, initial_size, + PROT_READ | PROT_WRITE , + MAP_PRIVATE | MAP_ANONYMOUS, + -1, 0); + printf("mmap returned : %p\n", mmap_ptr); + if (mmap_ptr == MAP_FAILED) { + perror("mmap"); + exit(1); + } + + const size_t new_size = 4096; + printf("calling mremap, size=%llu\n", (unsigned long long)new_size); + void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0); + printf("mremap returned: %p\n", remap_ptr); + if (remap_ptr != mmap_ptr) { + perror("mreamap"); + exit(1); + } + printf("Success: pointers match\n"); +} + + +This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts. I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245 + +Thanks to @LemonBoy for finding this: + +It looks like this issue my be caused by this chunk of code in linux-user/mmap.c + + if (prot == 0) { + host_addr = mremap(g2h(old_addr), old_size, new_size, flags); + if (host_addr != MAP_FAILED && reserved_va && old_size > new_size) { + mmap_reserve(old_addr + old_size, new_size - old_size); + } + } else { + errno = ENOMEM; + host_addr = MAP_FAILED; + } + +if new_size is less than old_size (which is the case in my example program) then we'll get an integer underflow which would cause a very large value passed to mmap_reserve + +I've submitted a patch, this is my first qemu patch so sorry if I didn't format it correctly: https://lists.gnu.org/archive/html/qemu-trivial/2020-05/msg00000.html + +FYI, first patch in the previous comment was wrong. This new patch is the correct one: https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg00183.html + + +Fix has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=257a7e212d5e518ac5 + +Patch has been included here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=257a7e212d5e518ac53b + diff --git a/results/classifier/108/other/1876568 b/results/classifier/108/other/1876568 new file mode 100644 index 00000000..c6d7803c --- /dev/null +++ b/results/classifier/108/other/1876568 @@ -0,0 +1,47 @@ +other: 0.800 +graphic: 0.738 +device: 0.713 +semantic: 0.657 +PID: 0.620 +performance: 0.588 +files: 0.584 +network: 0.559 +permissions: 0.533 +socket: 0.530 +vnc: 0.460 +debug: 0.389 +boot: 0.382 +KVM: 0.377 + +"semtimedop" implementation missing in qemu? + +I was trying to do an ARMv6 cross compile with qemu-user-static when I ran into this: + +https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/326884620#L1596 + +I was close to giving up when I found the following: + +https://github.com/osrf/multiarch-docker-image-generation/issues/36 + +Most important comment may be this one: + +https://github.com/osrf/multiarch-docker-image-generation/issues/36#issuecomment-610626796 + +> The "correct" way to fix this does seem to be to implement semtimedop in qemu. + +I don't know how much involved the people, discussing there, are in the qemu development but I thought it may be a good idea to bring this to your attention. If this is already fixed (I haven't found any bug about "semtimedop"), then please just close this one and tell me in which version the fix will be included. + +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 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. + + +[Expired for QEMU because there has been no activity for 60 days.] + |