diff options
Diffstat (limited to 'results/classifier/gemma3:12b/debug')
321 files changed, 15540 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/debug/100 b/results/classifier/gemma3:12b/debug/100 new file mode 100644 index 000000000..7899fddcf --- /dev/null +++ b/results/classifier/gemma3:12b/debug/100 @@ -0,0 +1,2 @@ + +GDB context is inconsistent after "monitor system_reset" diff --git a/results/classifier/gemma3:12b/debug/1001 b/results/classifier/gemma3:12b/debug/1001 new file mode 100644 index 000000000..7dcd022ab --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1001 @@ -0,0 +1,2 @@ + +query the current cursor position with QMP diff --git a/results/classifier/gemma3:12b/debug/1022 b/results/classifier/gemma3:12b/debug/1022 new file mode 100644 index 000000000..c57000986 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1022 @@ -0,0 +1,34 @@ + +RISC-V: Simulation terminated with seg fault when encountering `vsra.vx` +Description of problem: +QEMU simulation terminated with segmentation fault. Here is the backtrace of the simulation + +``` +(gdb) r +Starting program: qemu/build/qemu-riscv64 -cpu rv64,vext_spec=v1.0,v=true,Zfh=true,Zve32f=true,Zve64f=true,vlen=128 -B 0x100000 a.out +Missing separate debuginfos, use: yum debuginfo-install glibc-2.28-164.el8_5.3.x86_64 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +[New Thread 0x7ffff4edd700 (LWP 3239772)] + +Thread 1 "qemu-riscv64" received signal SIGSEGV, Segmentation fault. +0x00007fffe8004fad in code_gen_buffer () +Missing separate debuginfos, use: yum debuginfo-install glib2-2.56.4-156.el8.x86_64 gmp-6.1.2-10.el8.x86_64 gnutls-3.6.16-4.el8.x86_64 libffi-3.1-22.el8.x86_64 libidn2-2.2.0-1.el8.x86_64 libtasn1-4.13-3.el8.x86_64 libunistring-0.9.9-3.el8.x86_64 p11-kit-0.23.22-1.el8.x86_64 pcre-8.42-6.el8.x86_64 +(gdb) bt +#0 0x00007fffe8004fad in code_gen_buffer () +#1 0x00005555556a0b9b in cpu_tb_exec (tb_exit=<synthetic pointer>, itb=<optimized out>, cpu=0x7fffe8005000 <code_gen_buffer+20435>) at ../accel/tcg/cpu-exec.c:358 +#2 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x7fffe8005000 <code_gen_buffer+20435>) at ../accel/tcg/cpu-exec.c:848 +#3 cpu_exec (cpu=cpu@entry=0x555555eed3d0) at ../accel/tcg/cpu-exec.c:1007 +#4 0x00005555555e6d30 in cpu_loop (env=0x555555ef56f0) at ../linux-user/riscv/cpu_loop.c:37 +#5 0x00005555555df9f7 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../linux-user/main.c:909 +``` +Steps to reproduce: +1. Checkout to QEMU's latest master (`ec11dc41eec5142b4776db1296972c6323ba5847`) +2. `mkdir build ; cd build ; ../configure ; make -j24` +3. `qemu-riscv64 -cpu rv64,vext_spec=v1.0,v=true,Zfh=true,Zve32f=true,Zve64f=true,vlen=128 -B 0x100000 ./a.out` +Additional information: +Attaching code (output.c) and binary (a.out) + +[a.out](/uploads/0ecfb436a439619527ef645bdc781a48/a.out) + +[output.c](/uploads/cd492b4c9468f0b48412e76e7f6fcf91/output.c) diff --git a/results/classifier/gemma3:12b/debug/1030666 b/results/classifier/gemma3:12b/debug/1030666 new file mode 100644 index 000000000..8eaf6bf14 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1030666 @@ -0,0 +1,31 @@ + +gdb can't proceed after a breakpoint + +Using qemu-1.0.1-windows.zip package from http://lassauge.free.fr/qemu/ +Host: Windows 7 Ultimate 64-bit +Guest: i386 system running MS-DOS 6.22 +Launch command line: + qemu-system-i386.exe -L Bios -fda "DOS.vfd" -fdb "Data.vfd" -gdb tcp:127.0.0.1:1234 +Debbugers tried: + gdb 7.3.50.20111026-cvs running on Cygwin 1.7.16 + gdb 7.4 on MinGW + +Short description: +I use gdb to attach to a running Qemu session, set a breakpoint and resume execution. When the breakpoint is hit, gdb gains control as expected. However, trying to single-step or continue at this point just causes the same breakpoint to be hit immediately again. Deleting the breakpoint allows single-stepping or continue to work. + +Steps to reproduce: +DOS.vfd is a floppy image containing an MS-DOS 6.22 startup disk. +Data.vfd is a floppy image containing a single program (hello.com). +The aim is to debug the execution of hello.com with gdb. +Launch Qemu. +Launch gdb, an attach to qemu: + "target remote localhost:1234" +I know the address at which hello.com will be loaded, so set a breakpoint there and resume execution: + "break *0xf730" + "continue" +In Qemu, start hello.com. The breakpoint is immediately hit, execution stops and gdb gains control. +Examining the program gives expected results (such as "info reg" or "disassemble"). +At this point, try to proceed either with single-stepping ("si" or "ni") or with "continue", and the same breakpoint is immediately hit again. Subsequent attempts to single-step or continue just keep hitting the same breakpoint. +The only way to proceed at this point is to delete the breakpoint, after which both single-stepping and continue work. + +Note that single-stepping and continue works as expected if it is done after interrupting execution with Ctrl-C. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1031920 b/results/classifier/gemma3:12b/debug/1031920 new file mode 100644 index 000000000..315d58477 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1031920 @@ -0,0 +1,38 @@ + +Linux user gdbserver does not respond to remote `Ctrl-C' interrupts + +The bug was reproduce in a recent mainline build for ARM Linux by starting emulation with a gdbserver: + +$ qemu-arm -g 1234 a.out + +and then connecting from gdb: + +(gdb) target remote :1234 +Remote debugging using :1234 +[New Remote target] +[Switching to Remote target] +0x00008ba8 in _start () +(gdb) b main +Breakpoint 1 at 0x8cb0: file hello.c, line 5. +(gdb) cont +Continuing. + +Breakpoint 1, main (argc=1, argv=0xf6fff24c) at hello.c:5 +5 int n = 0; +(gdb) l +1 #include <stdio.h> +2 +3 int main (int argc, char **argv) +4 { +5 int n = 0; +6 +7 for (;;) { +8 printf ("Hello, World!\n"); +9 sleep (5); +10 } +(gdb) cont +Continuing. +^C^CInterrupted while waiting for the program. +Give up (and stop debugging it)? (y or n) y + +Notice that the `Ctrl-C' interrupts are ignored. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1047 b/results/classifier/gemma3:12b/debug/1047 new file mode 100644 index 000000000..98b1fb1a1 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1047 @@ -0,0 +1,105 @@ + +Single stepping Windows 10 bootloader results in Assertion `ret < cpu->num_ases && ret >= 0' failed. +Description of problem: +When I am trying to debug Windows bootloader, I see an assertion error in QEMU when single stepping some instructions in SeaBIOS. + +``` +qemu-system-i386: ../hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed. +``` +Steps to reproduce: +1. Download / construct `w.img`, see above +2. Start QEMU using `./qemu-system-i386 --drive media=disk,file=w.img,format=raw,index=1 -s -S -enable-kvm` +3. Start GDB using `gdb --ex 'target remote :::1234' --ex 'hb *0x7c00' --ex c --ex 'si 1000' --ex q` +4. See error message +Additional information: +The GDB script first breaks at 0x7c00, then tries to execute 1000 instructions using single step (`si`). On my machine, after executing around 772 instructions, the assertion error in QEMU happens. +Here is an interactive GDB session on my machine. + +``` +(gdb) hb *0x7c00 +Hardware assisted breakpoint 1 at 0x7c00 +(gdb) c +Continuing. + +Breakpoint 1, 0x00007c00 in ?? () +(gdb) d +Delete all breakpoints? (y or n) y +(gdb) si 770 +0x000f7d7b in ?? () +(gdb) x/10i $eip +=> 0xf7d7b: mov $0x7d85,%ebx + 0xf7d80: out %al,$0xb2 + 0xf7d82: pause + 0xf7d84: hlt + 0xf7d85: mov %bp,%sp + 0xf7d88: jmp 0xf7dd1 + 0xf7d8a: mov %cx,%si + 0xf7d8d: mov $0x1,%ax + 0xf7d91: add %al,(%eax) + 0xf7d93: callw 0x6b66 +(gdb) si +0x000f7d80 in ?? () +(gdb) info reg +eax 0xb5 181 +ecx 0x5678 22136 +edx 0x0 0 +ebx 0x7d85 32133 +esp 0xe96d4 0xe96d4 +ebp 0xfed4 0xfed4 +esi 0xe0346 918342 +edi 0xefd91 982417 +eip 0xf7d80 0xf7d80 +eflags 0x6 [ IOPL=0 PF ] +cs 0x8 8 +ss 0x10 16 +ds 0x10 16 +es 0x10 16 +fs 0x10 16 +gs 0x10 16 +fs_base 0x0 0 +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x11 [ ET PE ] +cr2 0x0 0 +cr3 0x0 [ PDBR=0 PCID=0 ] +cr4 0x0 [ ] +cr8 0x0 0 +efer 0x0 [ ] +... +mxcsr 0x1f80 [ IM DM ZM OM UM PM ] +(gdb) si +0x000f7d82 in ?? () +(gdb) info reg +eax 0xb5 181 +ecx 0x5678 22136 +edx 0x0 0 +ebx 0x7d85 32133 +esp 0xe96d4 0xe96d4 +ebp 0xfed4 0xfed4 +esi 0xe0346 918342 +edi 0xefd91 982417 +eip 0xf7d82 0xf7d82 +eflags 0x6 [ IOPL=0 PF ] +cs 0x8 8 +ss 0x10 16 +ds 0x10 16 +es 0x10 16 +fs 0x10 16 +gs 0x10 16 +fs_base 0x0 0 +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x11 [ ET PE ] +cr2 0x0 0 +cr3 0x0 [ PDBR=0 PCID=0 ] +cr4 0x0 [ ] +cr8 0x0 0 +efer 0x0 [ ] +... +mxcsr 0x1f80 [ IM DM ZM OM UM PM ] +(gdb) si +Remote connection closed +(gdb) +``` + +This bug was first incorrectly filed in KVM's bug tracker at <https://bugzilla.kernel.org/show_bug.cgi?id=216003>. diff --git a/results/classifier/gemma3:12b/debug/105 b/results/classifier/gemma3:12b/debug/105 new file mode 100644 index 000000000..050bd18fe --- /dev/null +++ b/results/classifier/gemma3:12b/debug/105 @@ -0,0 +1,2 @@ + +Gdb hangs when trying to single-step after an invalid instruction diff --git a/results/classifier/gemma3:12b/debug/1050694 b/results/classifier/gemma3:12b/debug/1050694 new file mode 100644 index 000000000..ef46d088e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1050694 @@ -0,0 +1,76 @@ + +Interrupt 0xffffffff when debug is turned on + +Hi, + +I have been getting a GPF when I enable interrupts, working on implementing processes and a scheduler. When I comment out the scheduler code, I still get the GPF. I used the following QEMU command line to capture a log: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + +Rather than posting the entire log, I need some help interpreting the following section (notice "INT=0xffffffff" on the top line): +Servicing hardware INT=0xffffffff +1: v=ffffffff e=0000 i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000 +EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780 +ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768 +EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl +GDT= 00127760 00000027 +IDT= 00122f40 000007ff +CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000024 CCD=0012b75c CCO=ADDL +EFER=0000000000000000 +check_exception old: 0xffffffff new 0xd +2: v=0d e=fffffffa i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000 +EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780 +ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768 +EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl +GDT= 00127760 00000027 +IDT= 00122f40 000007ff +CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000024 CCD=0012b75c CCO=ADDL +EFER=0000000000000000 + +To the best of my ability to interpret, I an getting an undefined interrupt, which is then triggering a GPF, which is caught. However, do not know where it might be coming from. + +Some additional information: + + +This command works: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -s -hda "$harddisk_image" -m 3.5G + + +This command works: + +qemu-system-i386 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + + +And, as above, this does not: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + + +[adam@os-development ~]$ qemu-system-i386 -version +QEMU emulator version 1.2.0, Copyright (c) 2003-2008 Fabrice Bellard + + +Attached is an image as a test case. Please let me know if you need any additional information. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1053 b/results/classifier/gemma3:12b/debug/1053 new file mode 100644 index 000000000..3cc98f1ad --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1053 @@ -0,0 +1,10 @@ + +Executable PMP regions of size less than 4K always trigger an instruction access fault +Description of problem: +When configuring a PMP region that is less than 4K in size (Page size), and then trying to execute instructions inside said region, TCG always throws a PMP exception, even though the area allows code execution. +Additional information: +I've debugged the issue already, and it's happening because of the following optimization in TCG: + +TCG uses `get_page_addr_code_hostp` in order to try and get the translation cached for a whole page of instructions; if this function is unable to translate a whole page, it's supposed to simply return `-1`, and then the caller is supposed to translate and execute on a per-instruction basis. In this case `get_page_addr_code_hostp` calls `tlb_fill`, which then calls `riscv_cpu_tlb_fill`, which then calls `get_physical_address_pmp` to perform the PMP access checks. When said instructions are covered by a PMP region which is smaller than a page, this check then fails, since PMP regions must cover the whole access in order to allow it. At this point `riscv_cpu_tlb_fill` will see that a PMP fault happened, and since `probe` is set to false by `get_page_addr_code_hostp`, it will throw a RISC-V access fault exception instead of just returning a failure that `get_page_addr_code_hostp` can handle (by only accessing the memory of the specific instruction instead, which will be fully covered by the PMP region). + +I haven't tried to fix it myself (my first idea is to simply make `get_page_addr_code_hostp` set the probe flag), since I'm not sure if changing that part of TCG will affect other architectures that I'm not aware of. diff --git a/results/classifier/gemma3:12b/debug/1059 b/results/classifier/gemma3:12b/debug/1059 new file mode 100644 index 000000000..92fb50981 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1059 @@ -0,0 +1,11 @@ + +qemu: uncaught target signal 6 (Aborted) - core dumped Issue +Description of problem: +When we are trying to use the docker images which is using Qemu internally in mac Os then we are getting the qemu: uncaught target signal 6 (Aborted) - core dumped Issue +Steps to reproduce: +1. https://botfront.io/docs/installation/local-machine install in local machine +2. run bot front run +3. Go to the docker dashboard and open the botfront-rasa. +4.  +Additional information: +Looking forward to get some updates regarding how we can solve this or any hack we can apply here. Thanks in advance. diff --git a/results/classifier/gemma3:12b/debug/1060 b/results/classifier/gemma3:12b/debug/1060 new file mode 100644 index 000000000..e6f36db4f --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1060 @@ -0,0 +1,34 @@ + +RISC-V: mtval/stval is not correctly set to the instruction itself on illegal instructions +Description of problem: +QEMU 7.0 claims to support `stval`/`mtval` for illegal instructions, but `mtval`/`stval` is actually set to `0` +Steps to reproduce: +1. Assemble and link `mtval-illegal.elf`. The code simply sets up a trap handler and generates an illegal instruction exception + +2. Start QEMU with: + + ``` + qemu-system-riscv64 -cpu rv64,h=off -bios mtval-illegal.elf -nographic -icount shift=0 -s -S + ``` + +3. Attach with GDB: + + ``` + gdb mtval-illegal.elf + + # Within GDB + target extended-remote :1234 + break trap + disp $mtval + + # Keep single stepping until breakpoint + stepi + ``` + +4. When control flow reaches `trap`, `mtval` is written with `0` instead of the encoding of `csrw time, x0` (`0xc0101073`) +Additional information: +Writing `0` to `mtval` on a illegal instruction trap is allowed by the specs, but since the [changelog of QEMU 7.0][changelog] says it should be supported, I would consider it a bug. + +[changelog]: https://wiki.qemu.org/ChangeLog/7.0#RISC-V + +I encountered this when trying to figure out why my program worked with QEMU 6 but breaks with QEMU 7. It's more complicated, but in that case I managed to get `mtval` written with neither `0` nor the actual illegal instruction, but a different illegal instruction. I will try gathering up all the dependencies and write down the steps to reproduce if needed and if I find the time. diff --git a/results/classifier/gemma3:12b/debug/1070 b/results/classifier/gemma3:12b/debug/1070 new file mode 100644 index 000000000..db6f4fda8 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1070 @@ -0,0 +1,11 @@ + +gdbstub XML generation for ARM is done for every CPU +Description of problem: +- As arm_cpu_register_gdb_regs_for_features is called from the device + realize stage for each vCPU in user mode we end up uselessly + regenerating the XML for every new thread. Once you get up to 100 + threads this starts exceeding the large maps done for QHT and PageDesc +Steps to reproduce: +See above command line, valgrind picks it up +Additional information: +See also #866, #967 diff --git a/results/classifier/gemma3:12b/debug/1072 b/results/classifier/gemma3:12b/debug/1072 new file mode 100644 index 000000000..0181b249b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1072 @@ -0,0 +1,25 @@ + +different behavior when remote debugger is used +Description of problem: +I found Qemu shows different behavior when I run Qemu with hello-world (statically linked binary enclosed) directly or run it through remote debugger. I need help to understand the following: + +1. Is this intended behavior? +1. Any way to make the two approaches have consistent behavior (I prefer the behavior shown in the 2nd approach described below) +1. If it is intended behavior, any explanation why or suggestions how to dig further to root cause the difference. + +The corresponding source code is the line 86 in [filedoalloc.c](https://code.woboq.org/userspace/glibc/libio/filedoalloc.c.html#86). It tests if the file (stdout) is char special device (S_ISCHR) +The preprocessed code is as follows: + if (((((st.st_mode)) & 0170000) == (0020000))) + +I then compared two different approaches to run Qemu: + +1. I used the following command line to collect the trace: qemu_aarch64 -strace -plugin $QEMU_ROOT/build/contrib/plugins/libexeclog.so -d plugin hello.a64. This one tests False for S_ISCHR +1. when I used gdb to connect to Qemu and single-step the instructions, S_ISCHR tests True, which is different from running qemu directly (approach 1). + +Thanks! +Steps to reproduce: +1.[hello.a64](/uploads/4b4ccae8c1e4b045c39ceae6a094d55a/hello.a64) +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/1077116 b/results/classifier/gemma3:12b/debug/1077116 new file mode 100644 index 000000000..3542260ba --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1077116 @@ -0,0 +1,54 @@ + +automoc4 segfaults when building in an armhf pbuilder on an amd64 host + +When trying to build kde4libs in an armhf pbuilder created with the pbuilder-scripts running on an amd64 host automoc4 recieves a segmentation fault and I can't get any useful information out of it: + +root@yofel-thinkpad:/tmp/kde4libs-4.9.3/build/kdeui# /usr/bin/automoc4 kdeui_automoc.cpp ../../kdeui/ . moc-qt4 cmake +unable to dump 00102c00 +Segmentation fault (core dumped) +root@yofel-thinkpad:/tmp/kde4libs-4.9.3/build/kdeui# gdb /usr/bin/automoc4 qemu_automoc4_20121108-211818_15839.core +GNU gdb (GDB) 7.5-ubuntu +Copyright (C) 2012 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "arm-linux-gnueabihf". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from /usr/bin/automoc4...done. +BFD: Warning: /tmp/kde4libs-4.9.3/build/kdeui/qemu_automoc4_20121108-211818_15839.core is truncated: expected core file size >= 5150720, found: 974848. +[New LWP 15839] +[New LWP 15866] +Cannot access memory at address 0xf67fe954 +Cannot access memory at address 0xf67fe950 +(gdb) bt +#0 0xf6630306 in ?? () +#1 0xf6415ff8 in ?? () +#2 0xf6415ff8 in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) + +automoc4 runs fine when building on a nexus7 so this sounds like an issue in qemu. +Tested in quantal and raring. + +ProblemType: Bug +DistroRelease: Ubuntu 13.04 +Package: qemu-user-static 1.2.0-2012.09-0ubuntu1 +Uname: Linux 3.6.2-030602-generic x86_64 +NonfreeKernelModules: nvidia +ApportVersion: 2.6.2-0ubuntu3 +Architecture: amd64 +Date: Fri Nov 9 19:29:28 2012 +EcryptfsInUse: Yes +InstallationDate: Installed on 2011-10-08 (398 days ago) +InstallationMedia: Kubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20111007) +MarkForUpload: True +ProcEnviron: + SHELL=/bin/bash + TERM=xterm + PATH=(custom, user) + LANG=en_US.UTF-8 + LANGUAGE=en_US.UTF-8 +SourcePackage: qemu-linaro +UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1079080 b/results/classifier/gemma3:12b/debug/1079080 new file mode 100644 index 000000000..07054d7c5 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1079080 @@ -0,0 +1,12 @@ + +ARM instruction "srs" wrong behaviour + +Quote from ARM Architecture Reference Manual ARMv7-A and ARMv7-R : +"Store Return State stores the LR and SPSR of the current mode to the stack of a specified mode" + +Problem: +When executing this instruction, the register stored is CPSR instead of SPSR. + +Context: +Using QEMU 1.2.0 to simulate a Zynq application (processor Cortex-a9 mpcore) with the following command line: +qemu-system-arm -M xilinx-zynq-a9 -m 512 -serial null -serial mon:stdio -dtb /home/vcesson/workspace/xilinx_zynq.dtb -kernel install/tests/io/serial/current/tests/serial2 -S -s -nographic \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1084148 b/results/classifier/gemma3:12b/debug/1084148 new file mode 100644 index 000000000..1db4da718 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1084148 @@ -0,0 +1,44 @@ + +Qt5 Beta 1 QProcess start and execute causes segmentation fault on armhf + +Steps +1) pbuilder-dist quantal armhf create +2) add ppa from https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta1 to the pbuilder +2.0) pbuilder-dist quantal armhf login +2.1) apt-get install software-properties-common +2.2) apt-add-repository ppa:canonical-qt5-edgers/qt5-beta1 +2.3) apt-get update +3) apt-get install qtbase qtdeclarative qttools bzr +4) bzr branch lp:~juhapekka-piiroinen/+junk/qemu-crash +5) cd qemu-crash; /opt/qt5/bin/qmake; make; ./untitled + +Expected Result: +Would execute 'ls' + +Actual result: +# ./untitled +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +Note: this code works on i386, amd64 and armel. + +Packages: +$ apt-cache policy qemu-user-static +qemu-user-static: + Installed: 1.2.0-2012.09-0ubuntu1 + Candidate: 1.2.0-2012.09-0ubuntu1 + Version table: + *** 1.2.0-2012.09-0ubuntu1 0 + 500 http://fi.archive.ubuntu.com/ubuntu/ quantal/universe amd64 Packages + 100 /var/lib/dpkg/status + 1.2.0-2012.09-0ubuntu1~linaro1 0 + 500 http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/ quantal/main amd64 Packages + +# apt-cache policy qtbase +qtbase: + Installed: 5.0-release~beta+20120831-1ubuntu54 + Candidate: 5.0-release~beta+20120831-1ubuntu54 + Version table: + *** 5.0-release~beta+20120831-1ubuntu54 0 + 500 http://ppa.launchpad.net/canonical-qt5-edgers/qt5-beta1/ubuntu/ quantal/main armhf Packages + 100 /var/lib/dpkg/status \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1105 b/results/classifier/gemma3:12b/debug/1105 new file mode 100644 index 000000000..6f1027463 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1105 @@ -0,0 +1,4 @@ + +QEMU gdbstub should support PAC for aarch64 +Additional information: +The fix should probably be in gdbstub.c diff --git a/results/classifier/gemma3:12b/debug/1119686 b/results/classifier/gemma3:12b/debug/1119686 new file mode 100644 index 000000000..5027bb2b3 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1119686 @@ -0,0 +1,16 @@ + +Incorrect handling of icebp + +Wine conformance suite tests the behavior of various low-level Windows API functions. One of the tests involves checking the interaction of breakpoints and exceptions, and in particular the 'icebp' breakpoint. This test works on a Windows XP machine running either on the metal or in VMware ESX but fails when run in QEmu. + +To reproduce the issue grab the attached 'exception.exe' file and run it. If you get 'Test failed' lines like below then it means the problem is still present: + + exception.c:202: exception 0: 80000004 flags:0 addr:003F0000 + exception.c:208: Test failed: 0: Wrong exception address 003F0000/003F0001 + exception.c:214: this is the last test seen before the exception + exception: unhandled exception 80000004 at 003F0000 + exception.c:202: exception 0: c0000027 flags:2 addr:7C80E0B9 + exception.c:205: Test failed: 0: Wrong exception code c0000027/80000004 + exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001 + +Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian Experimental). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1128 b/results/classifier/gemma3:12b/debug/1128 new file mode 100644 index 000000000..4d642fbe4 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1128 @@ -0,0 +1,25 @@ + +PPC: `spr_write_xer` doesn't set flag bits in `cpu_xer` +Description of problem: +`spr_write_xer()` does not set the `ca`, `ov`, `so`, `ca32`, `ov32` etc. flag bits in the `cpu_xer` variable. + +In fact it copies all bits from the source `GPR` and _excludes_ each flag bit. + +This is not a problem for execution since `spr_read_xer()` gets the flag bits from `cpu_ca/ov/so...` and not from `cpu_xer`. + +Nonetheless it is problem for tools which trace the execution in QEMU (e.g. https://github.com/BinaryAnalysisPlatform/qemu). + +A fix would be to remove the `~` in https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L481 +Steps to reproduce: +Haven't found out yet how to debug QEMU so the TCGv values can be investigated. But in general one need to: + +- Execute a binary which executes something like: +``` +r4 = 0xffffffffffffffff +mtxer r4 +``` +and check the `cpu_xer` value after the `xer` write. + +Checking the debug logs (`in_asm,cpu`) doesn't work, since the `xer` value in the logs is not taken directly from `cpu_xer`. +Additional information: +Code ref: https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L480-L483 diff --git a/results/classifier/gemma3:12b/debug/1133769 b/results/classifier/gemma3:12b/debug/1133769 new file mode 100644 index 000000000..452461a6c --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1133769 @@ -0,0 +1,28 @@ + +qtest failures leave orphaned qemu processes hanging around + +If a qtest test case fails, it leaves orphaned qemu processes hanging around. On Fedora 18 with qemu.git as of today ( Feb 26 2013), the patch just forces a test failure + +ps axwww | grep qemu | grep -v grep +$ make check-qtest-x86_64 + CC tests/rtc-test.o + LINK tests/rtc-test +GTESTER check-qtest-x86_64 + +$ ps axwww | grep qemu | grep -v grep +$ patch -p1 < force-test-failure.patch +patching file tests/rtc-test.c + +$ make check-qtest-x86_64 + CC tests/rtc-test.o + LINK tests/rtc-test +GTESTER check-qtest-x86_64 +** +ERROR:tests/rtc-test.c:256:bcd_check_time: assertion failed: (0) +GTester: last random seed: R02Sf2521dda395a2713128e0cbf86651a21 +make: *** [check-qtest-x86_64] Error 1 + +$ ps axwww | grep qemu | grep -v grep +26258 pts/0 Sl 0:00 x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-26256.sock,nowait -qtest-log /dev/null -qmp unix:/tmp/qtest-26256.qmp,nowait -pidfile /tmp/qtest-26256.pid -machine accel=qtest -display none -rtc clock=vm + +The problem is that an assertion failure in a test case causes the test program to exit(2) without hitting the qtest cleanup. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1143 b/results/classifier/gemma3:12b/debug/1143 new file mode 100644 index 000000000..3aed1b926 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1143 @@ -0,0 +1,79 @@ + +Breakpoints missed when a function is split into two memory pages. +Description of problem: +Qemu seems to ignore some breakpoints when the start of a function is +in another page than where the breakpoint is set. + +In my case, I've a function `__gnat_debug_raise_exception` which starts at `0x10bff2` and I've set with gdb a breakpoint at `0x10c00e` (in another page). +While running with `qemu -d in_asm,exec`, I can see that the whole function is executed at once and that no breakpoint is fired. + +``` +(gdb) b *0x00108fbc +(gdb) b *0x0010c00e +(gdb) target remote :1234 +(gdb) c + +Trace 0: 0x7f277c0174c0 [0000000000000000/0000000000108fb9/0040c0b0/ff000201] ada__exceptions__complete_occurrence +---------------- + +// gdb hits first breakpoint here. +Breakpoint 3, 0x0000000000108fbc .... +(gdb) ni + +IN: ada__exceptions__complete_occurrence +0x00108fbc: e8 31 30 00 00 callq 0x10bff2 + +Trace 0: 0x7f277c000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence +---------------- +IN: __gnat_debug_raise_exception +0x0010bff2: 55 pushq %rbp +0x0010bff3: 48 89 e5 movq %rsp, %rbp +0x0010bff6: 48 89 7d f8 movq %rdi, -8(%rbp) +0x0010bffa: 48 89 d1 movq %rdx, %rcx +0x0010bffd: 48 89 f0 movq %rsi, %rax +0x0010c000: 48 89 fa movq %rdi, %rdx +0x0010c003: 48 89 ca movq %rcx, %rdx +0x0010c006: 48 89 45 e0 movq %rax, -0x20(%rbp) +0x0010c00a: 48 89 55 e8 movq %rdx, -0x18(%rbp) +0x0010c00e: 48 8b 45 e0 movq -0x20(%rbp), %rax +0x0010c012: 90 nop +0x0010c013: 5d popq %rbp +0x0010c014: c3 retq + +Trace 0: 0x7f277c000100 [0000000000000000/000000000010bff2/0040c0b0/ff000000] __gnat_debug_raise_exception +Digging a bit more, it seems that it seems related to + +// gdb ni stop here. Breakpoints at 0x10c00e have been ignored. +``` + +Note that if I'm setting another breakpoint at `0x0010bffd` (thus not at the start of the function but still in the same page), the execution +will be executed step by step and the breakpoint at 0x10c00e will be triggered normally. + + +``` +IN: ada__exceptions__complete_occurrence +0x00108fbc: e8 31 30 00 00 callq 0x10bff2 + +Trace 0: 0x7f6af4000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence +---------------- +IN: __gnat_debug_raise_exception +0x0010bff2: 55 pushq %rbp + +Trace 0: 0x7f6af4000100 [0000000000000000/000000000010bff2/0040c0b0/ff000201] __gnat_debug_raise_exception +---------------- +IN: __gnat_debug_raise_exception +0x0010bff3: 48 89 e5 movq %rsp, %rbp + +Trace 0: 0x7f6af4000280 [0000000000000000/000000000010bff3/0040c0b0/ff000201] __gnat_debug_raise_exception +---------------- +IN: __gnat_debug_raise_exception +0x0010bff6: 48 89 7d f8 movq %rdi, -8(%rbp) +... +``` + +I've dug a bit into qemu translator code and I guess `check_for_breakpoint` should check that the whole function is in the same page before skipping step by step. But I'm not sure if it's possible because the TB is created after `check_for_breakpoint` IIUC. + +Sadly as of now, I don't have a C reproducer. I can try to provide you my "foo" program which is an Ada program. But maybe if you've a better idea how to reproduce that or an idea of to fix that, I'll be glad to help you. + +Thanks, +Clément diff --git a/results/classifier/gemma3:12b/debug/1145 b/results/classifier/gemma3:12b/debug/1145 new file mode 100644 index 000000000..d8d5916fc --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1145 @@ -0,0 +1,28 @@ + +Support register name resolution in debugger part of monitor for `x` commands for ARM platforms +Additional information: +From the looks of `get_monitor_def()` function from `monitor/misc.c` it seems to be cross-target but somehow still doesn't work for some targets anyway. + +Then grepping for the actual target implementation, it seems only i386, PPC, SPARC, and M68K support it, but nor ARM, MIPS, RISC V, etc: +``` +[i] ℤ rg monitor_defs +target/sparc/monitor.c +59:const MonitorDef monitor_defs[] = { +162:const MonitorDef *target_monitor_defs(void) +164: return monitor_defs; + +target/ppc/monitor.c +86:const MonitorDef monitor_defs[] = { +102:const MonitorDef *target_monitor_defs(void) +104: return monitor_defs; + +target/i386/monitor.c +611:const MonitorDef monitor_defs[] = { +647:const MonitorDef *target_monitor_defs(void) +649: return monitor_defs; + +target/m68k/monitor.c +25:static const MonitorDef monitor_defs[] = { +59:const MonitorDef *target_monitor_defs(void) +61: return monitor_defs; +``` diff --git a/results/classifier/gemma3:12b/debug/1163065 b/results/classifier/gemma3:12b/debug/1163065 new file mode 100644 index 000000000..769b37871 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1163065 @@ -0,0 +1,19 @@ + +target-i386 cpu_get_phys_page_debug checks bits in wrong order + +In target-i386 cpu_get_phys_page_debug, the CR4_PAE bit is checked before CR0_PG. This means that if paging is disabled but the PAE bit has been set in CR4, cpu_get_phys_page_debug will return the wrong result (it will try to translate the address as virtual rather than using it as a physical address). + +Although this might seem like an unusual case, it in fact happens consistently when booting Linux on amd64 (from linux-2.6.32.60/arch/x86/boot/compressed/head_64.S): + + /* Enable PAE mode */ + xorl %eax, %eax + orl $(X86_CR4_PAE), %eax + movl %eax, %cr4 +[... code to set up page tables omitted ...] + /* Enter paged protected Mode, activating Long Mode */ + movl $(X86_CR0_PG | X86_CR0_PE), %eax /* Enable Paging and Protected mode */ + movl %eax, %cr0 + +The most noticeable effect of this bug is that using the disassembler during this time will fetch the wrong data by trying to read from page tables that aren't there. One symptom is that booting Linux amd64 with -d in_asm will result in several "Disassembler disagrees with translator over instruction decoding" messages. + +Attached is a patch that moves the CR0_PG check to the beginning. I'm still not 100% certain that the logic of cpu_get_phys_page_debug matches cpu_x86_handle_mmu_fault, but it's a start. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1166 b/results/classifier/gemma3:12b/debug/1166 new file mode 100644 index 000000000..2a65efac3 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1166 @@ -0,0 +1,26 @@ + +Solaris 2.6 panic when debugging with gdb +Description of problem: +Running gdb with a breakpoint that gets hit triggers a panic: +``` +non parity synchronous error ctx=fa va=ef7d97c pa=c1a47c +``` + +One time I got of the following messages as well +``` +processor level 12 onboard interrupt not serviced +processor level 12 onboard interrupt not serviced +... +``` +Steps to reproduce: +1. Install Solaris 2.6 using https://learn.adafruit.com/build-your-own-sparc-with-qemu-and-solaris?view=all +2. Install https://archive.org/details/sun26gnu +3. Install http://download.nust.na/pub3/solaris/sunfreeware/pub/unixpackages/sparc/5.6/gdb-6.8-sol26-sparc-local.gz +4. Install http://download.nust.na/pub3/solaris/sunfreeware/pub/unixpackages/sparc/5.6/gcc-2.95.3-sol26-sparc-local.gz +5. Build a simple hello world program with debugging information +6. +``` +gdb ./hello +(gdb) break main +(gdb) run +``` diff --git a/results/classifier/gemma3:12b/debug/1169049 b/results/classifier/gemma3:12b/debug/1169049 new file mode 100644 index 000000000..7e20603c7 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1169049 @@ -0,0 +1,19 @@ + +do not stop on first gdb breakpoint with -enable-kvm + +I run qemu like this: + qemu-system-x86-64 -enable-kvm -hda <path to file> -s -S, + +and start gdb with commands like this: + gdb>tartget remote localhost:1234 + gdb>break *0x7c00 + gdb>c + +but gdb don't stop on it. I then could break execution manually and then breakpoints work. + +QEMU version: 1.4.0 (from Debian repos) +GDB version: 7.5.1 (copiled from sources, but previous was 7.4.1 from Debian repo) + +PS Same problem occure on Ubuntu 13.04 with same Qemu and Gdb 7.5.0 from repo. + +Thank you \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1180970 b/results/classifier/gemma3:12b/debug/1180970 new file mode 100644 index 000000000..02de8e600 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1180970 @@ -0,0 +1,39 @@ + +qemu: fatal: Trying to execute code outside RAM or ROM; worked in 1.4.0, fails in 1.4.92 + +I'm using qemu to run and debug the EDK2 uEFI environment. OVMF is being built out of the EDK2 tree I've checked out (r14367). (Reproducing all this could be tedious so I am available for debugging/testing.) + +qemu 1.4.0 was able to execute this guest environment with no trouble, qemu 1.4.92 however issues an error message and aborts. The command line I use to start qemu is: + +$ /usr/local/bin/qemu-system-x86_64 -m 1024 -bios OVMF.fd -monitor stdio + +1.4.92 gives the following register dump: + +QEMU 1.4.92 monitor - type 'help' for more information +(qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x0000000100000000 + +RAX=000000003e084da8 RBX=000000003e084868 RCX=0000000000000000 RDX=000000003e084f00 +RSI=0000000000000001 RDI=000000003e085000 RBP=000000003e084708 RSP=000000003fac8510 +R8 =0000000000000000 R9 =000000003e14c3e3 R10=0000000000000033 R11=00000000000000d3 +R12=000000003e0848a0 R13=0000000000000000 R14=0000000000000000 R15=0000000000000000 +RIP=00000000ffffffe4 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0028 0000000000000000 ffffffff 00af9b00 DPL=0 CS64 [-RA] +SS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0008 0000000000000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT +TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy +GDT= 000000003fa50e98 0000003f +IDT= 000000003f9d6e20 00000fff +CR0=80000033 CR2=0000000000000000 CR3=000000003fa67000 CR4=00000668 +... + + +Questions: +1) Is this problem relevant? (is full backward compatability to be supported?) +2) Are there new guest execution controls in 1.4.9x that might cause this? +3) If #2, can they be disabled by a qemu command line switch? +4) If not #2, in what qemu source file specifically can I find the logic causing the abort? (help me help you :) +5) If guest memory is corrupted or improperly mapped, how can I keep qemu alive to examime/dump guest memory? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1184 b/results/classifier/gemma3:12b/debug/1184 new file mode 100644 index 000000000..a65834372 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1184 @@ -0,0 +1,70 @@ + +Extra SIGTRAP when breakpoint + watchpoint occur on same instruction +Description of problem: +If a breakpoint and watchpoint occur on the same instruction in TCG, gdb receives a breakpoint notification, a watchpoint notification, and then a SIGTRAP not corresponding to any set breakpoint/watchpoint. +Steps to reproduce: +Start QEMU via: + +``` +./qemu-system-i386 -display none -accel tcg -kernel kernel.elf -s -S +``` + +Here's the gdb session: + +``` +(gdb) file kernel.elf +Reading symbols from kernel.elf...done. +(gdb) tar rem :1234 +Remote debugging using :1234 +0x0000fff0 in ?? () +(gdb) b _start +Breakpoint 1 at 0x10000c: file kernel.s, line 17. +(gdb) c +Continuing. + +Breakpoint 1, _start () at kernel.s:17 +17 mov eax, 3 +(gdb) b bp +Breakpoint 2 at 0x100011: file kernel.s, line 20. +(gdb) watch *(int*)&value +Hardware watchpoint 3: *(int*)&value +(gdb) c +Continuing. + +Breakpoint 2, bp () at kernel.s:20 +20 mov dword ptr value, eax +(gdb) c +Continuing. + +Hardware watchpoint 3: *(int*)&value + +Old value = 0 +New value = 3 +done () at kernel.s:23 +23 jmp done +(gdb) c +Continuing. + +Program received signal SIGTRAP, Trace/breakpoint trap. +done () at kernel.s:23 +23 jmp done +``` +Additional information: +This patch fixes it by disabling the extra debug interrupt if the CPU is already singlestepping, but I'm not certain it's the 'correct' fix? + +```patch +--- a/softmmu/physmem.c ++++ b/softmmu/physmem.c +@@ -894,7 +894,9 @@ void cpu_check_watchpoint(CPUState *cpu, vaddr addr, vaddr len, + * trigger after the current instruction. + */ + qemu_mutex_lock_iothread(); +- cpu_interrupt(cpu, CPU_INTERRUPT_DEBUG); ++ if ((cpu->singlestep_enabled & SSTEP_NOIRQ) == 0) { ++ cpu_interrupt(cpu, CPU_INTERRUPT_DEBUG); ++ } + qemu_mutex_unlock_iothread(); + return; + } + +``` diff --git a/results/classifier/gemma3:12b/debug/1184616 b/results/classifier/gemma3:12b/debug/1184616 new file mode 100644 index 000000000..becdbfe01 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1184616 @@ -0,0 +1,16 @@ + + undefined reference to `trace_qemu_anon_ram_alloc' + +The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) fails to compile: + +... + LINK qemu-ga +libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +oslib-posix.c:(.text+0x154): undefined reference to `trace_qemu_anon_ram_alloc' +libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +oslib-posix.c:(.text+0x1e7): undefined reference to `trace_qemu_anon_ram_free' +collect2: error: ld returned 1 exit status +make: *** [qemu-ga] Error 1 + +This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +'./configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1196498 b/results/classifier/gemma3:12b/debug/1196498 new file mode 100644 index 000000000..9649c7d36 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1196498 @@ -0,0 +1,25 @@ + +Failed to create COM port in Windows Guest VM + +Hi, + +Tried to establish virtual serial connection between two Windows Guest VMs(Windows 2008 Server). + +As it mentioned under the link, +http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging + +Started VM using the below command with serial device as TCP port. +# qemu-system-x86_64 -smp 1 -enable-kvm -m 512 -boot c -serial tcp:127.0.0.1:50001,server,nowait -hda /mnt/sda5/var/lib/libvirt/images/win2008host.img + +And started WinDbg in the Windows VM, with serial port:COM1 and Baudrate:115200. + +It throws the error "Could not start kernel debugging using com:port:COM1,baudrate:115200 parameters, Win32 error 0n2. The system cannot find the file specified." + +Checked under Device Manager and there is no COM1 port. +Does the -serial tcp:127.0.0.01:50001 creates COM1 port? I doubt. +If no what are the parameters I should pass to WinDbg for serial port? + +Please help me how to solve this issue. + +Thanks +Venkatesh \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1210212 b/results/classifier/gemma3:12b/debug/1210212 new file mode 100644 index 000000000..c7873d41a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1210212 @@ -0,0 +1,13 @@ + +qemu core dumps with -serial mon:vc + +qemu 1.5.2-1 dumps core when asked to put the monitor on a virtual console. For example, suppose you want to monitor the second serial port, you might try something like: + +qemu-system-x86_64 -serial null -serial mon:vc + +But that creates a core dump. In fact, even re-creating what should be the default dumps core: + +$ qemu-system-x86_64 -serial mon:vc:80Cx25C +Segmentation fault (core dumped) + +I'm not including a backtrace because the bug is so easy to reproduce, but I can provide more info if necessary. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1212 b/results/classifier/gemma3:12b/debug/1212 new file mode 100644 index 000000000..3d5c6105d --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1212 @@ -0,0 +1,10 @@ + +A NULL pointer dereference issue in elf2dmp +Description of problem: +SIGSEGV in get_pml4e for it didn't handle NULL result properly. +Steps to reproduce: +1.launch qemu and running "gab attach -p $QEMU_PID", run "gcore" inside gdb to generate coredump +2../elf2dmp ./core.111 ./out.dmp +3.get segemantation fault +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/1216845 b/results/classifier/gemma3:12b/debug/1216845 new file mode 100644 index 000000000..fbca2656b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1216845 @@ -0,0 +1,46 @@ + +qemu-system-arm semihosting always calls exit(0) + +In my embedded ARM project I have a bunch of unit tests that I run in a POSIX synthetic environment, and, as usual for POSIX processes, these tests return 0 for success and !=0 for error. + +Now I expanded the testing environment to run some of these tests compiled for ARM, under QEMU, with the tracing messages forwarded via the semihosting API. + +Up to now everything is fine with the emulation. + +However I have a problem with passing the failure code back to the operating system, to drive the continuous integration framework. + +I checked the arm-semi.c code and for SYS_EXIT and I discovered that the parameter passed is ignored and it always calls exit(0): + + case SYS_EXIT: + gdb_exit(env, 0); + exit(0); + +To solve my problem I temporarily made a patch, and for cases that should return non zero codes, I call an unsupported BKPT instruction, which makes QEMU abort, and pass an non zero code (1) back to the operating system. + + qemu: Unsupported SemiHosting SWI 0xf1 + +This kludge is more or less functional, but is quite inconvenient. + +After checking the ARM manuals, I discovered that SYS_EXIT is not standard, and the 0x18 code used for it originally was used for angel_SWIreason_ReportException, which has a slightly different purpose. + +Now the question: + +Would it be possible to no longer ignore the code passed to 0x18, and if it is non zero, to call exit() with a different value? + +The suggested rule would be: + +if (code ==0 || code == 0x20026) + exit(0); +elif (code < 256) + exit(code); +else + exit(1); + +The value 0x20026 means ADP_Stopped_ApplicationExit, and, if I understood it right, it means that the program terminated successfully. If this is not true, it can be removed from the first conditional statement. + +What do you think? Can this be added to arm-semi.c? + + +Regards, + +Liviu \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1217 b/results/classifier/gemma3:12b/debug/1217 new file mode 100644 index 000000000..114943b7b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1217 @@ -0,0 +1,131 @@ + +QEMU 6.2.0: Random segfaults when access register eax using qemu-system-x86_64 +Description of problem: +coredump info: +``` +(gdb) bt +#0 0x0000152016187387 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55 +#1 0x0000152016188a78 in __GI_abort () at abort.c:90 +#2 0x00001520159f2439 in os::abort (dump_core=<optimized out>) + at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:1572 +#3 0x0000152015c0e64a in VMError::report_and_die (this=this@entry=0x151fe009c4d0) + at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/share/vm/utilities/vmError.cpp:1112 +#4 0x00001520159fc5e5 in JVM_handle_linux_signal (sig=11, info=0x151fe009c770, ucVoid=0x151fe009c640, + abort_if_unrecognized=<optimized out>) + at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:541 +#5 0x00001520159ef5f8 in signalHandler (sig=11, info=0x151fe009c770, uc=0x151fe009c640) + at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:4591 +#6 <signal handler called> +#7 do_clone (pd=pd@entry=0x151fc7cfe700, attr=attr@entry=0x151fe009d410, stackaddr=<optimized out>, + stopped=<optimized out>, fct=0x152016b4fde0 <start_thread>, clone_flags=4001536) + at ../nptl/sysdeps/pthread/createthread.c:77 +#8 0x0000152016b5056a in create_thread (stackaddr=<optimized out>, attr=0x151fe009d410, pd=0x151fc7cfe700) + at ../nptl/sysdeps/pthread/createthread.c:244 +#9 __pthread_create_2_1 (newthread=<optimized out>, attr=<optimized out>, start_routine=<optimized out>, + arg=<optimized out>) at pthread_create.c:553 +#10 0x00001520159fb9b8 in os::create_thread (thread=0x561592f7f000, thr_type=<optimized out>, +---Type <return> to continue, or q <return> to quit---f 7 + stack_size=<optimized out>) + at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:921 +#11 0x00001520157eea78 in JVM_StartThread (env=<optimized out>, jthread=0x151fe009d4d0) + at /usr/src/debug/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64/openjdk/hotspot/src/share/vm/prims/jvm.cpp:3128 +#12 0x0000152001ef0c26 in ?? () +#13 0x00000006e100f538 in ?? () +#14 0x00000000de00bfff in ?? () +#15 0x0000151fe009d530 in ?? () +#16 0x0000152001915328 in ?? () +#17 0x00000006e100f538 in ?? () +#18 0x0000152010062550 in ?? () +#19 0x00000006f1450200 in ?? () +#20 0x00001520de280104 in ?? () +#21 0x0000000000000000 in ?? () +(gdb) f 7 +#7 do_clone (pd=pd@entry=0x151fc7cfe700, attr=attr@entry=0x151fe009d410, stackaddr=<optimized out>, + stopped=<optimized out>, fct=0x152016b4fde0 <start_thread>, clone_flags=4001536) + at ../nptl/sysdeps/pthread/createthread.c:77 +77 if (__builtin_expect (rc == -1, 0)) +(gdb) disas +Dump of assembler code for function do_clone: + 0x0000152016b4f010 <+0>: push %r12 + 0x0000152016b4f012 <+2>: xor %r12d,%r12d + 0x0000152016b4f015 <+5>: mov %rdx,%r10 + 0x0000152016b4f018 <+8>: push %rbp + 0x0000152016b4f019 <+9>: mov %rsi,%rbp + 0x0000152016b4f01c <+12>: push %rbx + 0x0000152016b4f01d <+13>: mov %rdi,%rbx + 0x0000152016b4f020 <+16>: sub $0x10,%rsp + 0x0000152016b4f024 <+20>: test %ecx,%ecx + 0x0000152016b4f026 <+22>: setne %r12b + 0x0000152016b4f02a <+26>: jne 0x152016b4f07f <do_clone+111> + 0x0000152016b4f02c <+28>: lock incl 0x21022d(%rip) # 0x152016d5f260 <__nptl_nthreads> + 0x0000152016b4f033 <+35>: lea 0x2d0(%rbx),%r8 + 0x0000152016b4f03a <+42>: lea 0xd9f(%rip),%rdi # 0x152016b4fde0 <start_thread> + 0x0000152016b4f041 <+49>: xor %eax,%eax + 0x0000152016b4f043 <+51>: mov %rbx,%r9 + 0x0000152016b4f046 <+54>: mov %rbx,%rcx + 0x0000152016b4f049 <+57>: mov $0x3d0f00,%edx + 0x0000152016b4f04e <+62>: mov %r8,(%rsp) + 0x0000152016b4f052 <+66>: mov %r10,%rsi + 0x0000152016b4f055 <+69>: callq 0x152016b4d470 <__clone@plt> +=> 0x0000152016b4f05a <+74>: cmp $0xffffffff,%eax + 0x0000152016b4f05d <+77>: je 0x152016b4f118 <do_clone+264> +---Type <return> to continue, or q <return> to quit---q +Quit +(gdb) p rc +$1 = 223935 +(gdb) i r rax +rax 0x36abf 223935 +(gdb) i r eax +eax 0x0 0 +(gdb) l +72 atomic_increment (&__nptl_nthreads); +73 +74 int rc = ARCH_CLONE (fct, STACK_VARIABLES_ARGS, clone_flags, +75 pd, &pd->tid, TLS_VALUE, &pd->tid); +76 +77 if (__builtin_expect (rc == -1, 0)) +78 { +79 atomic_decrement (&__nptl_nthreads); /* Oops, we lied for a second. */ +80 +81 /* Perhaps a thread wants to change the IDs and if waiting +(gdb) +``` +Additional information: +``` +# cat test.c +#include <stdlib.h> + +int main() { + int rc = test1(); + if(__builtin_expect (rc == -1, 0)) { + return rc; + } + + return 0; +} +# cat test_asm.s +global test1 +section .text +test1: + mov rax, 223935 + ret + +(gdb) disas main +Dump of assembler code for function main: + 0x00000000004004f6 <+0>: sub $0x8,%rsp + 0x00000000004004fa <+4>: mov $0x0,%eax + 0x00000000004004ff <+9>: callq 0x4004f0 <test1> + 0x0000000000400504 <+14>: cmp $0xffffffff,%eax + 0x0000000000400507 <+17>: sete %al + 0x000000000040050a <+20>: movzbl %al,%eax + 0x000000000040050d <+23>: neg %eax + 0x000000000040050f <+25>: add $0x8,%rsp + 0x0000000000400513 <+29>: retq +End of assembler dump. +... +# set breakpoint at 0x0000000000400504 +(gdb) i r eax +eax 0x36abf 223935 +(gdb) i r rax +rax 0x36abf 223935 +``` diff --git a/results/classifier/gemma3:12b/debug/1221966 b/results/classifier/gemma3:12b/debug/1221966 new file mode 100644 index 000000000..f5cdf4e70 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1221966 @@ -0,0 +1,35 @@ + +SIGSEGV in static_code_gen_buffer + +Trying to run 'ls' (or, anything else as far as I can tell) from a SunOS 5.8 box under RHEL 6.4 linux, I get a segfault. I've tried qemu-1.5.3, qemu-1.6.0, and I fetched git://git.qemu-project.org/qemu.git. I've also tried a statically linked sh from /sbin/ and it also segfaulted. + +wcolburn@anotheruvula</home/anotheruvula/qemu>$ gdb bin/qemu-sparc +GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) +Copyright (C) 2010 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "x86_64-redhat-linux-gnu". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from /home/anotheruvula/qemu/bin/qemu-sparc...done. +(gdb) run ../sparc/ls +Starting program: /home/anotheruvula/qemu/bin/qemu-sparc ../sparc/ls +[Thread debugging using libthread_db enabled] + +Program received signal SIGSEGV, Segmentation fault. +0x00007ffff8259116 in static_code_gen_buffer () +Missing separate debuginfos, use: debuginfo-install glib2-2.22.5-7.el6.x86_64 glibc-2.12-1.107.el6_4.4.x86_64 +(gdb) where +#0 0x00007ffff8259116 in static_code_gen_buffer () +#1 0x00007ffff7f570cd in cpu_tb_exec (cpu=0x7ffffa2b1210, tb_ptr= + 0x7ffff82590d0 "A\213n \205í\017\205Í") + at /home/anotheruvula/qemu-devel/cpu-exec.c:56 +#2 0x00007ffff7f57b2d in cpu_sparc_exec (env=0x7ffffa2b1348) + at /home/anotheruvula/qemu-devel/cpu-exec.c:631 +#3 0x00007ffff7f77f36 in cpu_loop (env=0x7ffffa2b1348) + at /home/anotheruvula/qemu-devel/linux-user/main.c:1089 +#4 0x00007ffff7f798ff in main (argc=2, argv=0x7fffffffdfc8, envp= + 0x7fffffffdfe0) at /home/anotheruvula/qemu-devel/linux-user/main.c:4083 +(gdb) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1225187 b/results/classifier/gemma3:12b/debug/1225187 new file mode 100644 index 000000000..37eeface0 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1225187 @@ -0,0 +1,13 @@ + +qemu hangs in windows 7 host with -serial pipe:windbg + +Execution line: +qemu-system-i386.exe -m 512 c:\Disks\Qemu_XP_en.vhd -serial pipe:windbg + +It waits for the pipe. +Execute windbg +c:\WINDDK\7600.16385.1\Debuggers\windbg.exe -k com:pipe,port=\\.\pipe\windbg,resets=0,reconnect + +GUI black screen shown. QEMU hangs. + +qemu v1.5.3 (c0b1a7e207094dba0b37a892b41fe4cab3195e44). MinGW built. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1231 b/results/classifier/gemma3:12b/debug/1231 new file mode 100644 index 000000000..e152bc1ec --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1231 @@ -0,0 +1,14 @@ + +Loading migration of VM in debug state fails (with potential solution) +Description of problem: +``` +qemu-system-x86_64: invalid runstate transition: 'inmigrate' -> 'debug' +Aborted (core dumped) +``` +Steps to reproduce: +1. Start VM with gdbstub +2. Pause VM via gdbstub +3. Save migration snapshot via HMP: `migrate "exec: gzip -c > foo.gz"` +4. Start new QEMU instance from snapshot by adding these args to whatever you used to launch QEMU: `-incoming "exec: gzip -c -d foo.gz"` +Additional information: +This can be fixed by adding `{ RUN_STATE_INMIGRATE, RUN_STATE_DEBUG },` to `runstate_transitions_def` in `softmmu/runstate.c`. It's not clear if there are any negative ramifications of this, but it seems to work for me? diff --git a/results/classifier/gemma3:12b/debug/1234179 b/results/classifier/gemma3:12b/debug/1234179 new file mode 100644 index 000000000..d49746a13 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1234179 @@ -0,0 +1,158 @@ + +QEMU segfaults during Windows 7 unattended install + +During today's automated qemu.git testing, a segmentation fault while installing Windows 7 SP1 happened. + +qemu.git top commit: +10/02 01:30:24 INFO | git:0150| git commit ID is a684f3cf9b9b9c3cb82be87aafc463de8974610c (tag v1.4.0-4237-ga684f3c) + +commit a684f3cf9b9b9c3cb82be87aafc463de8974610c +Merge: 349cd52 1cf9412 +Author: Anthony Liguori <email address hidden> +Date: Mon Sep 30 17:15:27 2013 -0500 + + Merge remote-tracking branch 'kraxel/seabios-1.7.3.2' into staging + + # By Gerd Hoffmann + # Via Gerd Hoffmann + * kraxel/seabios-1.7.3.2: + update seabios from 1.7.2.2 to 1.7.3.2 + + Message-id: <email address hidden> + +We have the core file saved in our test servers, we can make arrangements to transfer it if there's someone interested in investigating further. The framework saved the 'bt full' of the core file, that was missing some debug info: + +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +Core was generated by `/usr/local/autotest/tests/virt/qemu/qemu -S -name virt-tests-vm1 -M pc -nodefau'. +Program terminated with signal 11, Segmentation fault. +#0 0x00007ffc8fb86cf0 in pixman_image_get_data () from /lib64/libpixman-1.so.0 +#0 0x00007ffc8fb86cf0 in pixman_image_get_data () from /lib64/libpixman-1.so.0 +No symbol table info available. +#1 0x00007ffc9165b05c in ?? () +No symbol table info available. +#2 0x00007ffc9382b540 in ?? () +No symbol table info available. +#3 0x00007ffc8f359a8d in clock_gettime () from /lib64/libc.so.6 +No symbol table info available. +#4 0x00007ffc9382b5a8 in ?? () +No symbol table info available. +#5 0x000000019382b4c0 in ?? () +No symbol table info available. +#6 0x0000000000000000 in ?? () +No symbol table info available. + +Extra info: + +Commits for the submodules: + +10/02 01:30:29 DEBUG|base_utils:0134| [stdout] Submodule path 'dtc': checked out 'bc895d6d09695d05ceb8b52486ffe861d6cfbdde' +10/02 01:30:51 DEBUG|base_utils:0134| [stdout] Submodule path 'pixman': checked out '97336fad32acf802003855cd8bd6477fa49a12e3' +10/02 01:30:58 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/SLOF': checked out '8cfdfc43f4c4c8c8dfa4b7cf16f7c19c84eee812' +10/02 01:31:16 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/ipxe': checked out '09c5109b8585178172c7608de8d52e9d9af0b680' +10/02 01:31:20 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/openbios': checked out '0f3d51ef22ec9166beb3ed434d253029ed7cfe84' +10/02 01:31:21 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/qemu-palcode': checked out 'c87a92639b28ac42bc8f6c67443543b405dc479b' +10/02 01:31:27 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/seabios': checked out 'ece025f5980bae88fa677bc9c0d24d2e580e205d' +10/02 01:31:28 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/sgabios': checked out '23d474943dcd55d0550a3d20b3d30e9040a4f15b' +10/02 01:31:31 DEBUG|base_utils:0134| [stdout] Submodule path 'roms/vgabios': checked out '19ea12c230ded95928ecaef0db47a82231c2e485' + +Configure options: + +10/02 01:31:32 DEBUG|base_utils:0099| Running '/usr/local/autotest/tmp/virt/src/qemu/configure --target-list=x86_64-softmmu --disable-strip --prefix=/usr/local/autotest/tests/virt/qemu/install_root' +10/02 01:31:35 DEBUG|env_proces:0829| (address cache) DHCP lease OK: 00:30:48:c5:d6:e2 --> 10.16.72.38 +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Install prefix /usr/local/autotest/tests/virt/qemu/install_root +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] BIOS directory /usr/local/autotest/tests/virt/qemu/install_root/share/qemu +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] binary directory /usr/local/autotest/tests/virt/qemu/install_root/bin +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] library directory /usr/local/autotest/tests/virt/qemu/install_root/lib +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] libexec directory /usr/local/autotest/tests/virt/qemu/install_root/libexec +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] include directory /usr/local/autotest/tests/virt/qemu/install_root/include +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] config directory /usr/local/autotest/tests/virt/qemu/install_root/etc +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] local state directory /usr/local/autotest/tests/virt/qemu/install_root/var +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Manual directory /usr/local/autotest/tests/virt/qemu/install_root/share/man +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] ELF interp prefix /usr/gnemul/qemu-%M +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Source path /usr/local/autotest/tmp/virt/src/qemu +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] C compiler cc +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Host C compiler cc +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] C++ compiler c++ +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Objective-C compiler cc +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] QEMU_CFLAGS -Werror -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] make make +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] install install +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] python python -B +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] smbd /usr/sbin/smbd +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] host CPU x86_64 +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] host big endian no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] target list x86_64-softmmu +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] tcg debug enabled no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] gprof enabled no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] sparse enabled no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] strip binaries no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] profiler no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] static build no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] -Werror enabled yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] pixman system +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] SDL support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] GTK support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] curses support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] curl support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] mingw32 support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Audio drivers oss +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Block whitelist (rw) +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Block whitelist (ro) +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VirtFS support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VNC support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VNC TLS support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VNC SASL support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VNC JPEG support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VNC PNG support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] VNC WS support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] xen support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] brlapi support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] bluez support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Documentation no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] GUEST_BASE yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] PIE yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] vde support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Linux AIO support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] ATTR/XATTR support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Install blobs yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] KVM support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] RDMA support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] TCG interpreter no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] fdt support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] preadv support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] fdatasync yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] madvise yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] posix_madvise yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] sigev_thread_id yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] uuid support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] libcap-ng support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] vhost-net support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] vhost-scsi support yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Trace backend nop +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] Trace output file trace-<pid> +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] spice support no (/) +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] rbd support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] xfsctl support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] nss used no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] libusb no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] usb net redir no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] GLX support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] libiscsi support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] build guest agent yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] QGA VSS support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] seccomp support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] coroutine backend ucontext +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] coroutine pool yes +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] GlusterFS support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] virtio-blk-data-plane no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] gcov gcov +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] gcov enabled no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] TPM support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] libssh2 support no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] TPM passthrough no +10/02 01:31:40 DEBUG|base_utils:0134| [stdout] QOM debugging yes +10/02 01:31:40 INFO |build_help:0617| Running parallel make on build dir +10/02 01:31:40 DEBUG|base_utils:0099| Running 'make -j 24' \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/124 b/results/classifier/gemma3:12b/debug/124 new file mode 100644 index 000000000..56deeaa47 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/124 @@ -0,0 +1,2 @@ + +SIGSEGV when reading ARM GIC registers through GDB stub diff --git a/results/classifier/gemma3:12b/debug/1241 b/results/classifier/gemma3:12b/debug/1241 new file mode 100644 index 000000000..519b5a10f --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1241 @@ -0,0 +1,14 @@ + +About showing the information of the csr +Description of problem: +cannot print the inforamtion after pulling the newest version of qemu +E.g info r csr +only fcsr frm fflags are shown. However , it should print out all the csrs such as mideleg mhartid etc in preivous version +info r mip +(GDB) Invalid register `mip' +Steps to reproduce: +1.running riscv64-unknown-elf-gdb kernel +2.target remote to the port i set in the xv6 makefile +3.type info r mip it shows the the probklem i mentioned above. I could use the print CSR in previous version of QEMU. +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/1258168 b/results/classifier/gemma3:12b/debug/1258168 new file mode 100644 index 000000000..037ac1f94 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1258168 @@ -0,0 +1,132 @@ + +QEMU fails to build on CentOS 5.10 with --disable-pie reporting "/usr/bin/ld: -f may not be used without -shared " + +fails for (7dc65c0 (HEAD, origin/master, origin/HEAD, master) Open 2.0 development tree): + +... +libtool --mode=link --tag=CC cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/don/qemu/dtc/libfdt -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/home/don/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -Wl,--warn-common -m64 -g -o vscclient libcacard/vscclient.o libcacard.la -Wc,-fstack-protector-all -lrt -pthread -L/lib64 -lgthread-2.0 -lglib-2.0 -lz -L/usr/kerberos/lib64 -lcurl -ldl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lidn -lssl -lcrypto -lz -luuid +cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/don/qemu/dtc/libfdt -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/home/don/qemu/tests -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -Wl,--warn-common -m64 -g -o .libs/vscclient libcacard/vscclient.o -Wl,-fstack-protector-all -pthread ./.libs/libcacard.so -L/lib64 -L/usr/kerberos/lib64 -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -lrt -lgthread-2.0 -lglib-2.0 -lcurl -ldl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lidn -lssl -lcrypto -lz -luuid -Wl,--rpath -Wl,/usr/local/lib +/usr/bin/ld: -f may not be used without -shared +collect2: ld returned 1 exit status +make: *** [vscclient] Error 1 + +rm -rf out/tmp;mkdir out/tmp;pushd out/tmp;../../configure --disable-pie;make V=1 1>zz1 2>&1;popd +~/qemu/out/tmp ~/qemu +Install prefix /usr/local +BIOS directory /usr/local/share/qemu +binary directory /usr/local/bin +library directory /usr/local/lib +libexec directory /usr/local/libexec +include directory /usr/local/include +config directory /usr/local/etc +local state directory /usr/local/var +Manual directory /usr/local/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/don/qemu +C compiler cc +Host C compiler cc +C++ compiler c++ +Objective-C compiler cc +ARFLAGS rv +CFLAGS -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g +QEMU_CFLAGS -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I$(SRC_PATH)/dtc/libfdt +LDFLAGS -Wl,--warn-common -m64 -g +make make +install install +python python +smbd /usr/sbin/smbd +host CPU x86_64 +host big endian no +target list alpha-softmmu arm-softmmu cris-softmmu i386-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu moxie-softmmu or32-softmmu ppc-softmmu ppc64-softmmu ppcemb-softmmu s390x-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu unicore32-softmmu x86_64-softmmu xtensa-softmmu xtensaeb-softmmu alpha-linux-user arm-linux-user armeb-linux-user cris-linux-user i386-linux-user m68k-linux-user microblaze-linux-user microblazeel-linux-user mips-linux-user mips64-linux-user mips64el-linux-user mipsel-linux-user mipsn32-linux-user mipsn32el-linux-user or32-linux-user ppc-linux-user ppc64-linux-user ppc64abi32-linux-user s390x-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user sparc32plus-linux-user sparc64-linux-user unicore32-linux-user x86_64-linux-user +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build no +-Werror enabled no +pixman system +SDL support yes +GTK support no +curses support yes +curl support yes +mingw32 support no +Audio drivers oss +Block whitelist (rw) +Block whitelist (ro) +VirtFS support yes +VNC support yes +VNC TLS support no +VNC SASL support yes +VNC JPEG support yes +VNC PNG support yes +VNC WS support no +xen support yes +brlapi support no +bluez support no +Documentation yes +GUEST_BASE yes +PIE no +vde support no +Linux AIO support no +ATTR/XATTR support yes +Install blobs yes +KVM support yes +RDMA support no +TCG interpreter no +fdt support yes +preadv support no +fdatasync yes +madvise yes +posix_madvise yes +sigev_thread_id yes +uuid support yes +libcap-ng support no +vhost-net support yes +vhost-scsi support yes +Trace backend nop +Trace output file trace-<pid> +spice support no (/) +rbd support no +xfsctl support no +nss used yes +libusb no +usb net redir no +GLX support yes +libiscsi support no +build guest agent yes +QGA VSS support no +seccomp support no +coroutine backend ucontext +coroutine pool yes +GlusterFS support no +virtio-blk-data-plane no +gcov gcov +gcov enabled no +TPM support no +libssh2 support no +TPM passthrough no +QOM debugging yes +vhdx yes + +I bisect'd this to: + +dcs-xen-53:~/qemu>git-bisect good +37746c5eacf309fa019ea0fa45f776c36c561457 is the first bad commit +commit 37746c5eacf309fa019ea0fa45f776c36c561457 +Author: Marc-André Lureau <email address hidden> +Date: Mon Feb 25 23:31:12 2013 +0100 + + build-sys: must link with -fstack-protector + + It is needed to give that flag to the linker as well, but latest + libtool 2.4.2 still swallows that argument, so let's pass it with + libtool -Wc argument. + + qemu-1.4.0/stubs/arch-query-cpu-def.c:6: undefined reference to `__stack_chk_guard' + + Signed-off-by: Marc-André Lureau <email address hidden> + Reviewed-by: Alon Levy <email address hidden> + +:100755 100755 33d3354ea30838694020660f5822f551293d7e9a ee2e7e8ad9b8a23af96e4e404e3f7658efcbe74b M configure +:100644 100644 edc2552f0886c99608b97f85bd932460fa50da73 36aba2de1fa9e0f8acde7640818e94a28dd03c80 M rules.mak \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1260 b/results/classifier/gemma3:12b/debug/1260 new file mode 100644 index 000000000..6e3f254bb --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1260 @@ -0,0 +1,2 @@ + +RISC-V sstatus register is missing in qemu console / gdb diff --git a/results/classifier/gemma3:12b/debug/1261743 b/results/classifier/gemma3:12b/debug/1261743 new file mode 100644 index 000000000..6e71f88eb --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1261743 @@ -0,0 +1,6 @@ + +trace-backend "simple" doesn't support "disable" property of event + +trace-backend "simple" generates wrong eventid in trace/generated-tracers.c after "disable" property occured in trace-events record. + +Result: missing or mixing logs in trace file. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1262 b/results/classifier/gemma3:12b/debug/1262 new file mode 100644 index 000000000..43cc60c4c --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1262 @@ -0,0 +1,2 @@ + +avocado test framework fails to report when QEMU exits unexpectedly diff --git a/results/classifier/gemma3:12b/debug/1265 b/results/classifier/gemma3:12b/debug/1265 new file mode 100644 index 000000000..895a3afe7 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1265 @@ -0,0 +1,2 @@ + +avocado should log all the guest console output until QEMU exits, not disconnect early diff --git a/results/classifier/gemma3:12b/debug/1274 b/results/classifier/gemma3:12b/debug/1274 new file mode 100644 index 000000000..0b7785ca7 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1274 @@ -0,0 +1,33 @@ + +Cannot debug init using "qemu -s -S" if init is compiled dynamically or if kvm is enabled +Description of problem: +I'm trying to connect from host to init process running in guest. I'm using this guide: https://qemu-project.gitlab.io/qemu/system/gdb.html . Everything works well, but there is two problems: +1. Debugging stops to work if I add "-enable-kvm" +2. Debugging stops to work if I remove "-static" when compiling init +Steps to reproduce: +I have absolutely fresh Debian sid system (as of 2022-10-22). I create the following file on it: +```c +#include <stdio.h> + +int +main () +{ + printf ("a\n"); + printf ("b\n"); + for (;;); +} +``` + +Then I compile it so: `gcc -static -g a.c`. Result is saved as `/root/a.out`. Then I run `sync; echo 3 > /proc/sys/vm/drop_caches; sync` to make sure this `/root/a.out` actually got to disk. + +Then I start the host system inside of qemu using well-known `-snapshot /dev/sda` trick. Exact command is here: + +```bash +qemu-system-x86_64 -daemonize -m 300M -s -S -kernel /vmlinuz -initrd /initrd.img -snapshot -append "root=/dev/sda init=/root/a.out" -drive file=/dev/sda,format=raw +``` + +(As you guessed, my disk has no partitions, it directly stores ext4 filesystem.) + +Then I type on host `gdb ./a.out`. And then inside of gdb I type `target remote localhost:1234`, then `br 7` (line 7 is `printf ("b\n")`, then `c`. Then guest OS boots and reaches init (i. e. `/root/a.out`). And then gdb actually pauses on line 7. I. e. everything works! + +But if I add `-enable-kvm` to qemu command line OR remove `-static` from gcc command line, then breakpoint doesn't work, i. e. gdb doesn't pause on breakpoint, the execution continues and the execution fails to infinite loop. diff --git a/results/classifier/gemma3:12b/debug/1277433 b/results/classifier/gemma3:12b/debug/1277433 new file mode 100644 index 000000000..a8f36a18c --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1277433 @@ -0,0 +1,88 @@ + +GDB context is inconsistent after "monitor system_reset" + +After a "monitor system_reset" the GDB view to the system state differs from QEMUs processor state. + +Breakpoint 8, _ARMV4_Exception_interrupt () at /home/sh/rtems-4.11/c/src/../../cpukit/score/cpu/arm/arm_exc_interrupt.S:74 +74 mov EXCHANGE_LR, lr +(gdb) info registers +r0 0x2027e8 2107368 +r1 0x204208 2114056 +r2 0x13 19 +r3 0x204238 2114104 +r4 0x0 0 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +sp 0x201480 0x201480 +lr 0x110958 1116504 +pc 0x11073c 0x11073c <_ARMV4_Exception_interrupt+4> +cpsr 0x192 402 +(gdb) monitor info registers +R00=002027e8 R01=00204208 R02=00000013 R03=00204238 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00201480 R14=00110958 R15=0011073c +PSR=00000192 ---- A irq32 +(gdb) monitor system_reset +(gdb) info registers +r0 0x2027e8 2107368 +r1 0x204208 2114056 +r2 0x13 19 +r3 0x204238 2114104 +r4 0x0 0 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +sp 0x201480 0x201480 +lr 0x110958 1116504 +pc 0x11073c 0x11073c <_ARMV4_Exception_interrupt+4> +cpsr 0x192 402 +(gdb) monitor info registers +R00=00000000 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=00100040 +PSR=400001d3 -Z-- A svc32 + +Why does the second "info registers" and "monitor info registers" differ? + +After a single instruction step they are synchronized at least on ARM (on SPARC this is different). + +(gdb) si +bsp_start_vector_table_end () at /home/sh/rtems-4.11/c/src/lib/libbsp/arm/realview-pbx-a9/../shared/start/start.S:144 +144 msr cpsr, r0 +(gdb) info registers +r0 0xd3 211 +r1 0x0 0 +r2 0x0 0 +r3 0x0 0 +r4 0x0 0 +r5 0x0 0 +r6 0x0 0 +r7 0x0 0 +r8 0x0 0 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +sp 0x0 0x0 +lr 0x0 0 +pc 0x100044 0x100044 <bsp_start_vector_table_end+4> +cpsr 0x400001d3 1073742291 +(gdb) monitor info registers +R00=000000d3 R01=00000000 R02=00000000 R03=00000000 +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00000000 +R12=00000000 R13=00000000 R14=00000000 R15=00100044 +PSR=400001d3 -Z-- A svc32 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1280 b/results/classifier/gemma3:12b/debug/1280 new file mode 100644 index 000000000..8a5b9c873 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1280 @@ -0,0 +1,9 @@ + +qemu-system-arm 7.1 can not boot my cortex-m55 image +Steps to reproduce: +``` +1.qemu-system-arm -cpu cortex-m55 -machine mps3-an547 -nographic -vga none -monitor none -semihosting -semihosting-config enable=on,target=native -kernel qemu_simu.elf +2.arm-none-eabi-gdb -ex "target extended-remote localhost:1234" qemu_simu.elf +``` +Additional information: +[qemu_simu.tar.gz](/uploads/b8b3bf0f4868fdbb22b19027f685b4f0/qemu_simu.tar.gz) diff --git a/results/classifier/gemma3:12b/debug/1281 b/results/classifier/gemma3:12b/debug/1281 new file mode 100644 index 000000000..66b4bd87e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1281 @@ -0,0 +1,2 @@ + +xv6 kernel problem in single step mode diff --git a/results/classifier/gemma3:12b/debug/1289 b/results/classifier/gemma3:12b/debug/1289 new file mode 100644 index 000000000..81bf02321 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1289 @@ -0,0 +1,2 @@ + +plugin get registers diff --git a/results/classifier/gemma3:12b/debug/1298442 b/results/classifier/gemma3:12b/debug/1298442 new file mode 100644 index 000000000..11a02b408 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1298442 @@ -0,0 +1,6 @@ + +build problem in qemu-2.0.0-rc0 No rule to make target `trace/generated-events.h' + +With qemu-2.0.0-rc0 on CentOS release 5.7 (Final) I get + +make: *** No rule to make target `trace/generated-events.h', needed by `Makefile'. Stop. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1302 b/results/classifier/gemma3:12b/debug/1302 new file mode 100644 index 000000000..a96b7bb2d --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1302 @@ -0,0 +1,18 @@ + +Per-thread logging flag must be made immutable +Description of problem: +The problem is that the code assumes it isn't possible to switch from global logging to per-thread logging and vice-versa per design, but it lags appropriate checks to enforce it. Enabling or disabling per-thread logging at runtime from the monitor causes unexpected results. +Steps to reproduce: +Enabling per-thread logging at runtime: + +1. Start QEMU : `./qemu-system-x86_64 -S -monitor stdio -D qemu.log.%d` +2. Enable per-thread logging from the HMP monitor : `(qemu) log tid` +3. Fails with `Filename template with '%d' required for 'tid'` even though such a template was passed with `-D`. + +Disabling per-thread logging at runtime: + +1. Start QEMU : `./qemu-system-x86_64 -S -monitor stdio -D qemu.log.%d -d tid,cpu_reset` +2. Disable per-thread logging from the HMP monitor: `(qemu) log cpu_reset` +3. QEMU creates a log file with a bogus `qemu.log.%d` name. +Additional information: +[Series](https://patchew.org/QEMU/20221104120059.678470-1-groug@kaod.org/) posted and already reviewed by @rth7680 . diff --git a/results/classifier/gemma3:12b/debug/1336194 b/results/classifier/gemma3:12b/debug/1336194 new file mode 100644 index 000000000..42307ba8e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1336194 @@ -0,0 +1,25 @@ + +Errors reporting in do_delvm caused a crash + +In case of multiple errors, it leads to a crash. + +Typical back trace: +#0 <in libc> in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 <in libc> in __GI_abort () at abort.c:90 +#2 <in libc> in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=<in libc> "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:196 +#3 <in libc> in malloc_printerr (action=3, str=<in libc> "double free or corruption (out)", ptr=<optimized out>) at malloc.c:4902 +#4 <in libc> in _int_free (av=<optimized out>, p=<in heap chunk>, have_lock=0) at malloc.c:3758 +#5 <in qemu binary> in error_free (err=<in heap chunk>) at util/error.c:166 +#6 <in qemu binary> in do_delvm (mon=<in heap chunk>, qdict=<optimized out>) at /home/qemudbg/src/qemu/savevm.c:1132 +#7 <in qemu binary> in handle_user_command (mon=mon@entry=<in heap chunk>, cmdline=<optimized out>) at /home/qemudbg/src/qemu/monitor.c:4167 +#8 <in qemu binary> in monitor_command_cb (opaque=<in heap chunk>, cmdline=<optimized out>, readline_opaque=<optimized out>) at /home/qemudbg/src/qemu/monitor.c:4878 +#9 <in qemu binary> in readline_handle_byte (rs=<in heap>, ch=<optimized out>) at util/readline.c:371 +#10 <in qemu binary> in monitor_read (opaque=<optimized out>, buf=<optimized out>, size=<optimized out>) at /home/qemudbg/src/qemu/monitor.c:4861 +#11 <in qemu binary> in qemu_chr_be_write (len=<optimized out>, buf=<in stack> "\n\003", s=<in heap chunk>) at qemu-char.c:165 +#12 tcp_chr_read (chan=<optimized out>, cond=<optimized out>, opaque=<in heap chunk>) at qemu-char.c:2487 +#13 <in libglib> in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0 +#14 <in qemu binary> in glib_pollfds_poll () at main-loop.c:190 +#15 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:235 +#16 main_loop_wait (nonblocking=<optimized out>) at main-loop.c:484 +#17 <in qemu binary> in main_loop () at vl.c:2051 +#18 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4507 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1338 b/results/classifier/gemma3:12b/debug/1338 new file mode 100644 index 000000000..d93eb31ee --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1338 @@ -0,0 +1,2 @@ + +Remove gprof diff --git a/results/classifier/gemma3:12b/debug/1346769 b/results/classifier/gemma3:12b/debug/1346769 new file mode 100644 index 000000000..5d8082925 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1346769 @@ -0,0 +1,37 @@ + +/proc/self/maps content returned to 32-bits guest under 64-bits qemu + +Reading /proc/self/maps a user doesn't get a stack record. Not all programs relies on the maps file but some do. + +The bug found by running 32-bits binaries with address sanitizer (Asan) instrumentations under 64-bit qemu. + +$ echo "int main() { return 0; }" > /tmp/test.c +$ gcc -m32 -fsanitize=address -fno-common -Wall -g -fPIC -o /tmp/test /tmp/test.c +$ qemu-i386-static /tmp/test +==4092==AddressSanitizer CHECK failed: /home/michail/Downloads/gcc-4.9.0/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:63 "(((uptr)&rl >= start && (uptr)&rl < end)) != (0)" (0x0, 0x0) + #0 0xf632ff01 (/home/michail/build/lib32/libasan.so.1+0x53f01) + #1 0xf6333f49 (/home/michail/build/lib32/libasan.so.1+0x57f49) + #2 0xf6338785 (/home/michail/build/lib32/libasan.so.1+0x5c785) + #3 0xf6338bd1 (/home/michail/build/lib32/libasan.so.1+0x5cbd1) + #4 0xf6331baf (/home/michail/build/lib32/libasan.so.1+0x55baf) + #5 0xf6331dca (/home/michail/build/lib32/libasan.so.1+0x55dca) + #6 0xf6331f5a (/home/michail/build/lib32/libasan.so.1+0x55f5a) + #7 0xf6330bd4 (/home/michail/build/lib32/libasan.so.1+0x54bd4) + #8 0xf67ebeec (/lib/ld-linux.so.2+0xeeec) + #9 0xf67de10e (/lib/ld-linux.so.2+0x110e) + +This happened because during initialization Asan can't find stack boundaries. + +For some reasons Qemu wants to report stack boundaries just for several arch targets skipping other ones. This is from linux-user/syscall.c open_self_maps() + +#if defined(TARGET_ARM) || defined(TARGET_M68K) || defined(TARGET_UNICORE32) + dprintf(fd, "%08llx-%08llx rw-p %08llx 00:00 0 [stack]\n", + (unsigned long long)ts->info->stack_limit, + (unsigned long long)(ts->info->start_stack + + (TARGET_PAGE_SIZE - 1)) & TARGET_PAGE_MASK, + (unsigned long long)0); +#endif + +Not very clear why the case covers just specific targets. + +This bug continues the previously reported issue with not hiden system map http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg02793.html. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1346784 b/results/classifier/gemma3:12b/debug/1346784 new file mode 100644 index 000000000..7a81d2f0a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1346784 @@ -0,0 +1,68 @@ + +qemu internal memory areas visible to a guest via /proc/self/maps + + +Qemu internal memory areas are not suppressed in the output and are visible to a guest via /proc/self/maps. + +$ echo "int main() { return 0; }" > /tmp/test.c +$ gcc -m32 -fsanitize=address -fno-common -Wall -g -fPIC -o /tmp/test /tmp/test.c +$ qemu-i386-static -R 0 /tmp/test + +We use -R option because the binary can't be executed under stock version of Qemu with address sanitizer instrumentations (Asan). + +Qemu memory map looks the following way where GUEST valid addresses are marked with ***** and invalid with @@@: + +***** 08048000-08049000 r-xp 00000000 08:01 28835889 /tmp/test +***** 08049000-0804a000 rw-p 00000000 08:01 28835889 /tmp/test +***** 1ffff000-24000000 rw-p 00000000 00:00 0 +***** 24000000-28000000 ---p 00000000 00:00 0 +***** 28000000-40000000 rw-p 00000000 00:00 0 +***** 40000000-40001000 ---p 00000000 00:00 0 +***** 40001000-40801000 rw-p 00000000 00:00 0 [stack] +***** 40801000-40821000 r-xp 00000000 08:01 26738694 /lib32/ld-2.19.so +***** 40821000-40822000 r--p 0001f000 08:01 26738694 /lib32/ld-2.19.so +***** 40822000-40823000 rw-p 00020000 08:01 26738694 /lib32/ld-2.19.so +***** 40823000-40827000 rw-p 00000000 00:00 0 +***** 40827000-408ca000 r-xp 00000000 08:01 49424994 /home/michail/build/lib32/libasan.so.1.0.0 +***** 408ca000-408cc000 rw-p 000a3000 08:01 49424994 /home/michail/build/lib32/libasan.so.1.0.0 +***** 408cc000-40d24000 rw-p 00000000 00:00 0 +***** 40d3c000-40ee2000 r-xp 00000000 08:01 26738695 /lib32/libc-2.19.so +***** 40ee2000-40ee4000 r--p 001a6000 08:01 26738695 /lib32/libc-2.19.so +***** 40ee4000-40ee5000 rw-p 001a8000 08:01 26738695 /lib32/libc-2.19.so +***** 40ee5000-40ee8000 rw-p 00000000 00:00 0 +***** 40ee8000-40f00000 r-xp 00000000 08:01 26738711 /lib32/libpthread-2.19.so +***** 40f00000-40f01000 r--p 00017000 08:01 26738711 /lib32/libpthread-2.19.so +***** 40f01000-40f02000 rw-p 00018000 08:01 26738711 /lib32/libpthread-2.19.so +***** 40f02000-40f04000 rw-p 00000000 00:00 0 +***** 40f04000-40f07000 r-xp 00000000 08:01 26738708 /lib32/libdl-2.19.so +***** 40f07000-40f08000 r--p 00002000 08:01 26738708 /lib32/libdl-2.19.so +***** 40f08000-40f09000 rw-p 00003000 08:01 26738708 /lib32/libdl-2.19.so +***** 40f09000-40fee000 r-xp 00000000 08:01 49424965 /home/michail/build/lib32/libstdc++.so.6.0.20 +***** 40fee000-40ff2000 r--p 000e5000 08:01 49424965 /home/michail/build/lib32/libstdc++.so.6.0.20 +***** 40ff2000-40ff3000 rw-p 000e9000 08:01 49424965 /home/michail/build/lib32/libstdc++.so.6.0.20 +***** 40ff3000-40ffa000 rw-p 00000000 00:00 0 +***** 40ffa000-4103e000 r-xp 00000000 08:01 26738698 /lib32/libm-2.19.so +***** 4103e000-4103f000 r--p 00043000 08:01 26738698 /lib32/libm-2.19.so +***** 4103f000-41040000 rw-p 00044000 08:01 26738698 /lib32/libm-2.19.so +***** 41040000-41041000 rw-p 00000000 00:00 0 +***** 41041000-4105b000 r-xp 00000000 08:01 49424637 /home/michail/build/lib32/libgcc_s.so.1 +***** 4105b000-4105c000 rw-p 00019000 08:01 49424637 /home/michail/build/lib32/libgcc_s.so.1 +***** 4105c000-4105e000 rw-p 00000000 00:00 0 +***** 4105f000-41061000 rw-p 00000000 00:00 0 +***** 41065000-421ed000 rw-p 00000000 00:00 0 +***** 421ee000-421f1000 rw-p 00000000 00:00 0 +***** 60000000-6033b000 r-xp 00000000 08:01 48760980 /home/michail/build/bin/qemu-i386-static +***** 6053b000-60546000 rw-p 0033b000 08:01 48760980 /home/michail/build/bin/qemu-i386-static +***** 60546000-6059a000 rw-p 00000000 00:00 0 +***** 6059a000-6259b000 rwxp 00000000 00:00 0 +***** 6259b000-625ae000 rw-p 00000000 00:00 0 +***** 62dce000-62e12000 rw-p 00000000 00:00 0 [heap] +@@@ 7f3f5e6a9000 - 7f3f61f28000 rw-p 00000000 00:00 0 +@@@ 7fffad130000 - 7fffad132000 r-xp 00000000 00:00 0 [vdso] +@@@ ffffffffff600000 - ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] + +qemu-i386-static and its heap are in ranges which are valid and be reported to guest in case of maps file reading. + +The issue is related to early reported bugs: +http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg02793.html +http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg03085.html \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1347 b/results/classifier/gemma3:12b/debug/1347 new file mode 100644 index 000000000..a1d2c4057 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1347 @@ -0,0 +1,24 @@ + +qemu-system-arm segfaults: arm_v7m_tcg_ops.restore_state_to_opc is NULL +Description of problem: +gdb backtrace: +``` +#0 0x0000000000000000 in ?? () +#1 0x0000555555eda714 in cpu_restore_state_from_tb (cpu=0x5555570020e0, tb=0x7fffb8f6ce80, host_pc=140735277023274) at ../accel/tcg/translate-all.c:311 +#2 0x0000555555eda785 in cpu_restore_state (cpu=0x5555570020e0, host_pc=140735277023274) at ../accel/tcg/translate-all.c:335 +#3 0x0000555555d01323 in arm_cpu_do_transaction_failed (cs=0x5555570020e0, physaddr=1073885184, addr=1073885184, size=4, access_type=MMU_DATA_LOAD, mmu_idx=1, attrs=..., response=1, retaddr=140735277023274) at ../target/arm/tlb_helper.c:199 +#4 0x0000555555ee4118 in cpu_transaction_failed (cpu=0x5555570020e0, physaddr=1073885184, addr=1073885184, size=4, access_type=MMU_DATA_LOAD, mmu_idx=1, attrs=..., response=1, retaddr=140735277023274) at ../accel/tcg/cputlb.c:1344 +#5 0x0000555555ee42aa in io_readx (env=0x555557003f50, full=0x5555580f26c0, mmu_idx=1, addr=1073885184, retaddr=140735277023274, access_type=MMU_DATA_LOAD, op=MO_32) at ../accel/tcg/cputlb.c:1380 +#6 0x0000555555ee59f2 in load_helper (env=0x555557003f50, addr=1073885184, oi=33, retaddr=140735277023274, op=MO_32, code_read=false, full_load=0x555555ee5dbf <full_le_ldul_mmu>) at ../accel/tcg/cputlb.c:1970 +#7 0x0000555555ee5e12 in full_le_ldul_mmu (env=0x555557003f50, addr=1073885184, oi=33, retaddr=140735277023274) at ../accel/tcg/cputlb.c:2070 +#8 0x0000555555ee5e44 in helper_le_ldul_mmu (env=0x555557003f50, addr=1073885184, oi=33, retaddr=140735277023274) at ../accel/tcg/cputlb.c:2077 +#9 0x00007fff7c31c0be in code_gen_buffer () +#10 0x0000555555ed15b8 in cpu_tb_exec (cpu=0x5555570020e0, itb=0x7fffb8f6ce80, tb_exit=0x7fff7a3fc068) at ../accel/tcg/cpu-exec.c:438 +#11 0x0000555555ed2185 in cpu_loop_exec_tb (cpu=0x5555570020e0, tb=0x7fffb8f6ce80, pc=2824872, last_tb=0x7fff7a3fc080, tb_exit=0x7fff7a3fc068) at ../accel/tcg/cpu-exec.c:868 +#12 0x0000555555ed2545 in cpu_exec (cpu=0x5555570020e0) at ../accel/tcg/cpu-exec.c:1032 +#13 0x0000555555ef3329 in tcg_cpus_exec (cpu=0x5555570020e0) at ../accel/tcg/tcg-accel-ops.c:69 +#14 0x0000555555ef39ca in mttcg_cpu_thread_fn (arg=0x5555570020e0) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#15 0x00005555560b1e87 in qemu_thread_start (args=0x5555571358e0) at ../util/qemu-thread-posix.c:505 +#16 0x00007ffff7fb6cbe in start (p=0x7fff7a3fc1e0) at src/thread/pthread_create.c:195 +#17 0x00007ffff7fc3e7b in __clone () at src/thread/x86_64/clone.s:22 +``` diff --git a/results/classifier/gemma3:12b/debug/1359930 b/results/classifier/gemma3:12b/debug/1359930 new file mode 100644 index 000000000..380948c86 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1359930 @@ -0,0 +1,44 @@ + +[ARMv5] Integrator/CP regression when reading FPSID register + +There seems to be a regression in QEMU 2.1.0 which demonstrates itself +when running the attached HelenOS Integrator/CP (i.e. ARMv5) image. The +offending instruction seems to be: + + vmrs r0, fpsid + +Upon its execution, HelenOS kernel receives an Undefined instruction +exception (which it does not anticipate at that point) and crashes. + +QEMU 2.0.0 was not affected by this issue. + +Command line to reproduce with QEMU 2.1.0: + +$ qemu-system-arm -M integratorcp -kernel image.boot -s -S & +$ /usr/local/cross/arm32/bin/arm-linux-gnueabi-gdb +... +(gdb) target remote localhost:1234 +Remote debugging using localhost:1234 +warning: Can not parse XML target description; XML support was disabled at compile time +0x00000000 in ?? () +(gdb) symbol-file kernel/kernel.raw +Reading symbols from /home/jermar/software/HelenOS.mainline/kernel/kernel.raw...done. +(gdb) break ras_check +Breakpoint 1 at 0x80a021bc: file arch/arm32/src/ras.c, line 67. +(gdb) c +Continuing. + +Breakpoint 1, ras_check (n=1, istate=0x813e7f70) at arch/arm32/src/ras.c:67 +67 { +(gdb) set radix 16 +Input and output radices now set to decimal 16, hex 10, octal 20. +(gdb) print istate->pc +$1 = 0x80a02458 +(gdb) disassemble 0x80a02458 +Dump of assembler code for function fpsid_read: + 0x80a02454 <+0>: vmrs r0, fpsid <======= UNDEFINED EXCEPTION INSTRUCTION + 0x80a02458 <+4>: mov pc, lr +End of assembler dump. + + +The Undefined instruction exception is not expected at this point when executing the VMRS r0,fpsid instruction. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1363 b/results/classifier/gemma3:12b/debug/1363 new file mode 100644 index 000000000..2cf25bf91 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1363 @@ -0,0 +1,4 @@ + +TriCore: writing to registers is not working (as it's supposed to) +Description of problem: +Reading the tricore register list from QEMU works just fine. However, writing this registers is not working as expected. It looks like the bug is on QEMU's side, since third party gdb client faces the same issues. diff --git a/results/classifier/gemma3:12b/debug/1364501 b/results/classifier/gemma3:12b/debug/1364501 new file mode 100644 index 000000000..2b015b24d --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1364501 @@ -0,0 +1,21 @@ + +Gdb hangs when trying to single-step after an invalid instruction + +When using Gdb to remote-debug a program and manually setting its PC to point to an address containing an invalid instruction, then doing a single step Qemu will never return control to the remote Gdb. + +For instance, let's say address 0x114 contains an invalid instruction. On the remote Gdb, we'd do: + +(gdb) set $pc = 0x114 +(gdb) stepi + +After doing that we won't get the (gdb) prompt unless we do a Ctrl-C. If we do so we'll be left at 0x114 instead of going towards the exception handler as we should. This happens with stepi, step and next. If instead of single-stepping we used continue, the program will proceed into the exception handler as it should. + +The reason this is happening is that when Qemu realizes it's about to translate an instruction it doesn't recognize it'll generate a call to helper_exception_with_syndrome(), which will register the exception and then call cpu_loop_exit(). At the same time, because we're doing a single-step, Qemu will also generate a call to helper_exception_internal() passing it an EXCP_DEBUG, which lets the system know it'll give control back to the remote debugger, and it also ends with a call to cpu_loop_exit(). However, because the syndrome exception calls cpu_loop_exit() first, the call to the internal exception won't be reached and Qemu will be stuck in a loop without returning control to the remote debugger. + +What makes this a bit tricky to fix is that we must call cpu_loop_exit() at the end of helper_exception_with_syndrome(), otherwise the target exception will go undetected and its handler won't be excecuted. + +Tested on latest head by emulating a Stellaris lm3s6965 board and running RTEMS 4.11: + +$ qemu-system-arm -nographic -s -S -M lm3s6965evb -kernel my_rtems_app + +Commit hash in qemu.git: 30eaca3acdf17d7bcbd1213eb149c02037edfb0b \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1382 b/results/classifier/gemma3:12b/debug/1382 new file mode 100644 index 000000000..57aecd948 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1382 @@ -0,0 +1,41 @@ + +x86-64 In long mode the Selector Error Code has an improperly encoded Selector Index when dealing with IDT descriptor indexes +Description of problem: +When in long mode an IDT descriptor is 16 bytes in size. When an exception is raised where an index to an IDT descriptor entry needs to be encoded in an error code's selector index field it appears that QEMU's software emulation improperly encodes the IDT descriptor index as if each entry is 8 bytes rather than 16. The effect is that the descriptor index is encoded with a value that is double what it should be. + +As an example if I have a *Segment Not Present* (#NP) exception handler (which has a selector error code pushed on the stack) that is raised when I try to generate a software interrupt 0x97 that is marked not present in its IDT descriptor entry - I expect that QEMU would properly encode the value 0x97 in the Selector Index of the Selector Error Code pushed on the stack. Instead, the value stored is actually 0x12E. 0x12E is double the expected value 0x97. + +You can observe this errant value in the output of QEMU when using the `-d int` option. I have cut out the unnecessary state information as I'm focussed on the `v=` and `e=`. + + 0: v=97 e=0000 i=1 cpl=0 IP=0008:0000000000008a0a pc=0000000000008a0a SP=0010:0000000000007c00 + 1: v=0b e=0972 i=0 cpl=0 IP=0008:0000000000008a0a pc=0000000000008a0a SP=0010:0000000000007c00 + +When I used `int 0x97` to generate the software interrupt it properly shows that `v=97` had occurred in the output above. Because 0x97 was marked not present exception 0x0b (Not Present) was raised as you can see in the second line. The problem is that `e=0972` is a Selector Error Code where *Bits 3..16* contain the value 0x12E instead of 0x97. **It isn't just the display value in QEMU's debug output that is wrong**, as the **Selector Error Code pushed on the interrupt stack is the same erroneous value**. + +This issue doesn't occur if you run QEMU with the `-enable-kvm` option; in BOCHS; or on real hardware. The value in those environments contains a Selector Error Code of 0x4ba. *Bits 3..16* of 0x4ba contains the descriptor index 0x97 as expected. See additional information for more details. +Steps to reproduce: +1. Put processor in long mode. 64-bit mode will suffice. +2. Load an IDT with: + - A valid Segment Not Present (#NP) 0x0B Exception Handler. Handler doesn't really need to do anything. + - At least one interrupt handler marked *Not Present* higher than 0x00. Interrupt 0x97 as an example. +3. Raise the interrupt with something like `int 0x097` for this example. +Additional information: +In order to test this problem out in other environments like real hardware and virtual machines I wrote a test program on a floppy disk image that can be run on machines and virtual machines that support legacy boot from floppy media (or emulated floppy media). The test program code can be found [in my Github repository](https://github.com/mpetch/SelectorErrorCodeTest). A pre-built [disk image](https://github.com/mpetch/SelectorErrorCodeTest/blob/main/disk.img) is also available. + +When the disk image is executed with QEMU using `qemu-system-x86_64 -fda disk.img` the result (with incorrect encoding) can be seen here: + + + +When QEMU is run with `qemu-system-x86_64 -fda disk.img -enable-kvm` the result (with correct encoding) can be seen here: + + + +Correct results are also obtained in BOCHS and real hardware. + +--- +The [Intel Software Development Manual Volume 3A](https://www.intel.ca/content/www/ca/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html) documents the error code as: + + + +--- +# diff --git a/results/classifier/gemma3:12b/debug/1391942 b/results/classifier/gemma3:12b/debug/1391942 new file mode 100644 index 000000000..982f60588 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1391942 @@ -0,0 +1,18 @@ + +Unnecessary events option of the trace argument with UST backend + +When running configure with the --enable-trace-backends=ust option the user should not have to specify a the "events" and "file" options because they are not used with that tracing framework. + +Right now, in order the use this option the need to specify a dummy events file. + +This fails: +$> qemu-system-x86_64 -hda debian_wheezy_amd64_standard.qcow2 -trace -m 512 +qemu-system-x86_64: -trace -m: Invalid parameter '-m' + +This works: +$> qemu-system-x86_64 -hda debian_wheezy_amd64_standard.qcow2 -trace events=dummy-events.txt -m 512 +VNC server running on `127.0.0.1:5900' + +I am using version: +$> qemu-system-x86_64 --version +QEMU emulator version 2.1.90, Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1397 b/results/classifier/gemma3:12b/debug/1397 new file mode 100644 index 000000000..f5325f13a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1397 @@ -0,0 +1,2 @@ + +riscv: break, hbreak does not set a breakpoint on the correct address when providing symbols diff --git a/results/classifier/gemma3:12b/debug/1401 b/results/classifier/gemma3:12b/debug/1401 new file mode 100644 index 000000000..204c59a88 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1401 @@ -0,0 +1,21 @@ + +configure uses break outside loop +Description of problem: +When running `configure` in version 7.2.0, the following message is printed multiple times: + +``` +qemu/configure: line 1885: break: only meaningful in a `for', `while', or `until' loop +``` +Steps to reproduce: +Running `configure` should be enough. My complete configure command is: + +``` +/bin/bash ./configure \ + --prefix=$PREFIX/qemu --sysconfdir=/etc$PREFIX/qemu \ + --includedir=$PREFIX/qemu/include --bindir=$PREFIX/qemu/bin \ + --sbindir=$PREFIX/qemu/sbin --libdir=$PREFIX/qemu/lib/amd64 \ + --libexecdir=$PREFIX/qemu/libexec/amd64 \ + --localstatedir=/var$PREFIX/qemu +``` +Additional information: +The `configure` script has `break;` in a conditional, where `:` would suffice (or the conditional could just be negated) diff --git a/results/classifier/gemma3:12b/debug/1404690 b/results/classifier/gemma3:12b/debug/1404690 new file mode 100644 index 000000000..514cbe7a6 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1404690 @@ -0,0 +1,39 @@ + +Qemu crashes with chrooted m68k + +I'm using qemu-m68k 2.2.0 to chroot into a m68k coldfire linux, which works fine on the coldfire machine. + +I've been able to use binfmt_msc and used the above code to use qemu with strace: + +#include <unistd.h> +#include <string.h> + +int main(int argc, char **argv, char **envp) { + char *newargv[argc + 4]; + + newargv[0] = argv[0]; + newargv[1] = "-cpu"; + newargv[2] = "cfv4e"; + newargv[3] = "-strace"; + + memcpy(&newargv[4], &argv[1], sizeof(*argv) * (argc - 1)); + newargv[argc + 3] = NULL; + return execve("/usr/bin/qemu-m68k", newargv, envp); +} + +Everything works fine. I can run bash, busybox, ash, but when I try to run a ls or just type an invalid command, I got the attached sequence of messages, which end like so: + +11351 waitpid(-1,0xf6fffa00,0x3) = -1 errno=10 (No child processes) +qemu: fatal: Illegal instruction: 0000 @ f6fffa30 +D0 = ffffffff A0 = f67dcf50 F0 = 0000000000000000 ( 0) +D1 = 0000000a A1 = f66e0898 F1 = 0000000000000000 ( 0) +D2 = f6fffaa8 A2 = f67df268 F2 = 0000000000000000 ( 0) +D3 = 00000000 A3 = 00000000 F3 = 0000000000000000 ( 0) +D4 = 00000008 A4 = 800026c4 F4 = 0000000000000000 ( 0) +D5 = 00000000 A5 = f67d98e0 F5 = 0000000000000000 ( 0) +D6 = f6fffaa8 A6 = f6fffa7c F6 = 0000000000000000 ( 0) +D7 = 00000002 A7 = f6fffa24 F7 = 0000000000000000 ( 0) +PC = f6fffa30 SR = 0000 ----- FPRESULT = 0 +Aborted + +How can I debug it further to try to figure out if this is a qemu issue or not? Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/141 b/results/classifier/gemma3:12b/debug/141 new file mode 100644 index 000000000..b5477ff08 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/141 @@ -0,0 +1,2 @@ + +qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options diff --git a/results/classifier/gemma3:12b/debug/1417 b/results/classifier/gemma3:12b/debug/1417 new file mode 100644 index 000000000..baec0d87b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1417 @@ -0,0 +1,6 @@ + +QEMU fails an assertion when hitting a breakpoint that is set on a tlb-missed 2-stage translated AArch64 memory +Description of problem: +After upgrading to QEMU v7.2.0 from v7.1.0, when hitting an instruction breakpoint on a memory address that is translated by 2 stages of translation, and is not already cached in the TLB, QEMU fails the assertion at target/arm/ptw.c:301 (`assert(fi->type != ARMFault_None);`). + +I believe this was introduced in f3639a64f602ea5c1436eb9c9b89f42028e3a4a8 (@rth7680), since in that commit the failure check for the return value of `get_phys_addr_lpae()` changed from checking for true (meaning failure) to checking for false (which actually means success). diff --git a/results/classifier/gemma3:12b/debug/1421 b/results/classifier/gemma3:12b/debug/1421 new file mode 100644 index 000000000..8a32a2e82 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1421 @@ -0,0 +1,20 @@ + +GDB memory reads fail on Cortex-M33 +Description of problem: +GDB fails to read memory from the guest. There appear to be at least two problems: + +1. In `arm_cpu_get_phys_page_attrs_debug`, `arm_is_secure(env)` returns false, because the implementation doesn't seem to know about Armv7-M or Armv8-M secure states. However, `arm_mmu_idx(env)` does know how to check `env->v7m.secure`, so it returns `ARMMMUIdx_MSPriv` (the S stands for secure). The mismatch between an apparently non-secure access to a secure MMU seems to cause the read to fail laster. +2. With the MPU enabled (not the case in this repro, but I can provide one), `cpu_memory_rw_debug` computes `page = addr & TARGET_PAGE_MASK`, and uses the page to compute permissions. However, TARGET_PAGE_MASK is based on 4K pages on this platform, but the MPU granularity is 32 bytes. So the wrong page is used for checking. +Steps to reproduce: +``` +# Sorry for the large clone. It's mostly unused files in CMSIS. +git clone --recursive -b qemu-repro-1 https://github.com/dreiss/mpu_experiments +cd mpu_experiments +git checkout origin/qemu-repro-1 +cmake -S . -B build -DBOARD=qemu-mps2-an505 -DAPP=mpu_stacktrace -DCMAKE_BUILD_TYPE=Debug +cmake --build build +/path/to/qemu-system-arm -machine mps2-an505 -nographic -kernel build/kernel.elf -s -S -d int +# Open a separate terminal and cd into mpu_experiments +gdb build/kernel.elf -ex 'target remote :1234' -ex 'break base_case' -ex continue -ex backtrace -ex quit +# Note the memory read failures in the backtrace. +``` diff --git a/results/classifier/gemma3:12b/debug/1428657 b/results/classifier/gemma3:12b/debug/1428657 new file mode 100644 index 000000000..6f27a41c3 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1428657 @@ -0,0 +1,71 @@ + +qemu-system-arm does not ignore the lowest bit of pc when returning from interrrupt + +This was observed in qemu v2.1.3, running a sample app from + +FreeRTOS(FreeRTOSV7.5.2/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo) + +In the sample code compiled with arm-none-eabi-gcc , version 4.8.2 (4.8.2-14ubuntu1+6) . + +qemu seems to be executing the wrong instrunction after returning from the SVCHandler. The svc handler changes the PSP register and the new stack contains an add return address, which should be allowed(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka12545.html). The lowest bit of the address should be ignored, but it seems that qemu executes garbage after returning from the interrupt. + +qemu is run like this: + +qemu-system-arm -semihosting -machine lm3s6965evb -kernel RTOSDemo.axf -gdb tcp::1234 -S + + +this is the arm-gdb trace +Program received signal SIGINT, Interrupt. +IntDefaultHandler () at startup.c:231 +231 { +(gdb) bt +#0 IntDefaultHandler () at startup.c:231 +#1 0xfffffffc in ?? () + +(gdb) info registers +r0 0x0 0 +r1 0x14b4b4b4 347387060 +r2 0xa5a5a5a5 -1515870811 +r3 0xa5a5a53d -1515870915 +r4 0xa5a5a5a5 -1515870811 +r5 0xa5a5a5a5 -1515870811 +r6 0xa5a5a5a5 -1515870811 +r7 0x40d00542 1087374658 +r8 0xa5a5a5a5 -1515870811 +r9 0xa5a5a5a5 -1515870811 +r10 0xa5a5a5a5 -1515870811 +r11 0xa5a5a5a5 -1515870811 +r12 0xa5a5a5a5 -1515870811 +sp 0x20008380 0x20008380 +lr 0xfffffffd -3 +pc 0xc648 0xc648 <IntDefaultHandler> +cpsr 0x20000173 536871283 + +this exception occur after running SVC handler code + +(gdb) disassemble vPortSVCHandler +Dump of assembler code for function vPortSVCHandler: + 0x0000c24c <+0>: ldr r3, [pc, #24] ; (0xc268 <vPortSVCHandler+28>) + 0x0000c24e <+2>: ldr r1, [r3, #0] + 0x0000c250 <+4>: ldr r0, [r1, #0] + 0x0000c252 <+6>: ldmia.w r0!, {r4, r5, r6, r7, r8, r9, r10, r11} + 0x0000c256 <+10>: msr PSP, r0 + 0x0000c25a <+14>: mov.w r0, #0 + 0x0000c25e <+18>: msr BASEPRI, r0 + 0x0000c262 <+22>: orr.w lr, lr, #13 + 0x0000c266 <+26>: bx lr + 0x0000c268 <+28>: andcs r2, r0, r12, ror #5 +End of assembler dump. + +This stores this stack in PSP register: +(gdb) x /32 0x200052c8 +0x200052c8: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 +0x200052d8: 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 0xa5a5a5a5 +0x200052e8: 0x00000000 0x14b4b4b4 0xa5a5a5a5 0xa5a5a53d +0x200052f8: 0xa5a5a5a5 0x00000000 0x00003b49 0x21000000 +0x20005308: 0xa5a5a5a5 0xa5a5a5a5 0x200081b8 0x00000058 +0x20005318: 0x00000000 0x00000000 0x00000000 0x00000000 +0x20005328: 0x00000000 0x20005330 0xffffffff 0x20005330 +0x20005338: 0x20005330 0x00000000 0x20005344 0xffffffff + +It seems that qemu actually executes 0x00003b49 after the interrupt, but it should execute 0x00003b48 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1463338 b/results/classifier/gemma3:12b/debug/1463338 new file mode 100644 index 000000000..f914159fd --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1463338 @@ -0,0 +1,15 @@ + +qemu-system-arm injects #UND exception with wrong PC + +Usually all accesses to coprocessor registers are only possible in PL1 or higher. When accessing a coprocessor register in user mode, QEMU generates a trap and the PC of the trapping instruction is passed to the OS with an offset of+ 4. Some coprocessor registers can be configured to allow access to them in usermode (PL0). The latest qemu-git (ee09f84e6bf5383a23c9624115c26b72aa1e076c) seems to add an offest of 8 instead of four if such a register is accessed from user mode. This happens only if the coprocessors register that is accessed might also be accessed from PL0. In case all accesses to the coprocessor register from PL0 cause a trap, qemu injects the #UND trap with the correct PC value. + +Attached is a small test program that installs a signal handler for "SIGILL". On a pandaboard the progam prints "Val=0x2 Val2=0x2" whereas on the latest "qemu-system-arm" the output is : "Val=0x1 Val2=0x2" + +Qemu was configured with: "./configure --python=`which python2.7` --target-list=arm-softmmu" +The test can be compiled with: "gcc -g -static test2.c -o test2" + +If further information is needed, feel free to ask. + +Regards, + +Robert \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1468 b/results/classifier/gemma3:12b/debug/1468 new file mode 100644 index 000000000..792e37a22 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1468 @@ -0,0 +1,7 @@ + +qemu hangs on white windows when connecting to virtual port using -serial option when using Windows OS +Description of problem: +I was trying to connect windbg with a qemu vm. +First I try using named pipes but all the tutorials I found online result in the qemu windows not even showing. So I give up and trying to use virtual COMs to connect the qemu machine with windbg over serial port. So I created using professional Virtual come driver a link between COM2 and COM4. Now I run qemu with -serial COM2 and I do not run windbg than it run correctly and no problem is present. As soon as I run windbg qemu hangs at startup just after the main window is created. The qemu window remains white and windows shows the normal "The application is not responding". It's like the program is in a infinite loop situation. +Also I noted that If I run qemu and not windbg as soon as the other COM port is connected qemu would stop working and remain frozed. Again showing the "The application is not responding". +If instead of qemu I use other "commercial" software with the same setup (of course there I could use named pipes anyway) I can connect windbg with the machine and do the debug session. diff --git a/results/classifier/gemma3:12b/debug/1488 b/results/classifier/gemma3:12b/debug/1488 new file mode 100644 index 000000000..888319984 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1488 @@ -0,0 +1,36 @@ + +Memory not accessible from GDB when using mps3-an547 +Description of problem: +Memory (including variables) is not accessible when connecting to the emulated machine via GDB +Steps to reproduce: +1. Create minimal program `main.c`: + ```c + int main(void) { + int myvar = 42; + for(;;) + } + ``` +2. Compile + ```bash + arm-none-eabi-gcc -c -o build/main.o -c -mcpu=cortex-m55 -mfloat-abi=hard -mthumb -funsigned-char -mlittle-endian -O0 -g -std=c11 main.c + ``` + (ARM startup files and include directories omitted for brevity) +3. Link + ```bash + arm-none-eabi-g++ -o build/test.elf build/main.o -mcpu=cortex-m55 -mfloat-abi=hard -mthumb -funsigned-char -mlittle-endian --entry=Reset_Handler -static -T./platform.ld -O0 -g + ``` + (ARM startup files omitted for brevity) +4. Run binary in QEMU: + ```bash + qemu-system-arm --machine mps3-an547 -serial mon:stdio -kernel test.elf -gdb tcp::1234 -S + ``` +5. Attach using GDB `arm-none-eabi-gdb build/test.elf` and set break point to infinite loop + ```gdb + target remote :1234 + break main.c:18 + continue + print myvar + ``` + +Expected Output: 42 +Actual Output: `Cannot access memory at address 0x11fffe4` diff --git a/results/classifier/gemma3:12b/debug/1489 b/results/classifier/gemma3:12b/debug/1489 new file mode 100644 index 000000000..15b5dc76d --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1489 @@ -0,0 +1,95 @@ + +Breakpoints set at wrong addresses in `test-gdbstub.py` for some Linux kernels guest images +Description of problem: +The script `tests/guest-debug/test-gdbstub.py` for testing QEMU's GDB +stub on Linux kernel guests sets breakpoints on `kernel_init()` and +`wait_for_completion()`. As the script is coded, breakpoints are set +(implicitly) not at the functions' start addresses, but at the end of +the functions' prologues. + +For some Linux kernel builds in which `kernel_init()` and +`wait_for_completion()` get compiled with a function prologue, the +script fails to detect breakpoint hits in `check_hbreak()` and +`check_break()` because it compares the stopped address (i.e. the end of +the function's prologue) with the function's start address, and they +differ. To observe the difference in GDB: + +```sh +$ gdb -q --nx vmlinux +Reading symbols from vmlinux... +(gdb) b kernel_init +Breakpoint 1 at 0xffff800008fbeb28: file init/main.c, line 1497. # <- prologue start +(gdb) b *kernel_init +Breakpoint 2 at 0xffff800008fbeb18: file init/main.c, line 1491. # <- function start +``` + +In my tests, the issue doesn't occur with standard Linux kernels builds +(e.g. compiled on Linux hosts with GCC) because typically both +`kernel_init()` and `wait_for_completion()` seem to be without +prologues. +Steps to reproduce: +The issue has so far been encountered only with arm64 Linux kernel +guests compiled on macOS arm64 with +[mac-linux-kdk](https://github.com/GayPizzaSpecifications/mac-linux-kdk). + +1. Compile a recent arm64 Linux kernel on macOS arm64 with debugging + information (first `make defconfig`, then `make menuconfig` and set + `Kernel hacking / Compile-time checks and compiler options / Debug + information / Rely on toolchain's implicit default DWARF version`) + + ```sh + $ file /tmp/linux-5.19/arch/arm64/boot/Image + /tmp/linux-5.19/arch/arm64/boot/Image: Linux kernel ARM64 boot executable Image, little-endian, 4K pages + $ file /tmp/linux-5.19/vmlinux + /tmp/linux-5.19/vmlinux: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[sha1]=bf9e422d48e0aded5859fe34d6de2c174ef3a20b, with debug_info, not stripped + ``` + +2. Start QEMU waiting for GDB to connect: + + ```sh + $ ./qemu-system-aarch64 -smp 1 -M virt -cpu cortex-a57 -kernel /tmp/linux-5.19/arch/arm64/boot/Image -append nokaslr -s -S + ``` + +3. Execute the `test-gdbstub.py` script (as described in the script file + itself): + + ```sh + $ gdb /tmp/linux-5.19/vmlinux -x tests/guest-debug/test-gdbstub.py + ``` + + The script then hangs. + +Tested both on a macOS host and a Linux host. +Additional information: +The proposed fix is to explicitly disable GDB's prologue decoder and set +the two breakpoints at the functions' start addresses [by adding an +asterisk before the function +name](https://stackoverflow.com/a/31451340): + +```diff +diff --git a/tests/guest-debug/test-gdbstub.py b/tests/guest-debug/test-gdbstub.py +index 98a5df4d4..6202d17c3 100644 +--- a/tests/guest-debug/test-gdbstub.py ++++ b/tests/guest-debug/test-gdbstub.py +@@ -31,7 +31,7 @@ def check_step(): + def check_break(sym_name): + "Setup breakpoint, continue and check we stopped." + sym, ok = gdb.lookup_symbol(sym_name) +- bp = gdb.Breakpoint(sym_name) ++ bp = gdb.Breakpoint("*%s" % (sym_name)) + + gdb.execute("c") + +@@ -48,7 +48,7 @@ def check_break(sym_name): + def check_hbreak(sym_name): + "Setup hardware breakpoint, continue and check we stopped." + sym, ok = gdb.lookup_symbol(sym_name) +- gdb.execute("hbreak %s" % (sym_name)) ++ gdb.execute("hbreak *%s" % (sym_name)) + gdb.execute("c") + + # hopefully we came back +``` + +This change shouldn't impact the Linux kernel guests for which the +script is already working as intended. diff --git a/results/classifier/gemma3:12b/debug/1492 b/results/classifier/gemma3:12b/debug/1492 new file mode 100644 index 000000000..b7fd6791e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1492 @@ -0,0 +1,293 @@ + +[coredump] [git master] qemu-x86_64 segfaults on ppc64le (4K page size) when trying to run android-studio inside chroot +Description of problem: +qemu-x86_64 segfaults when trying to run android-studio inside an Arch Linux x86_64 chroot from a Gentoo Linux ppc64le (4K page size) host. Hardware is a Raptor CS Talos 2 Power 9. +``` +[niko@talos2 ~]$ android-studio +/usr/bin/android-studio: line 200: 117922 Segmentation fault (core dumped) "$JAVA_BIN" -classpath "$CLASS_PATH" ${VM_OPTIONS} "-XX:ErrorFile=$HOME/java_error_in_studio_%p.log" "-XX:HeapDumpPath=$HOME/java_error_in_studio_.hprof" "-Djb.vmOptionsFile=${USER_VM_OPTIONS_FILE:-${VM_OPTIONS_FILE}}" ${IDE_PROPERTIES_PROPERTY} -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.strict.classpath=true -Didea.vendor.name=Google -Didea.paths.selector=AndroidStudio2022.1 -Didea.platform.prefix=AndroidStudio -Didea.jre.check=true -Dsplash=true com.intellij.idea.Main "$@" +``` +Steps to reproduce: +1. Create an Arch Linux chroot from a bootstrap tarball: https://wiki.archlinux.org/title/Install_Arch_Linux_from_existing_Linux#Method_A:_Using_the_bootstrap_tarball_(recommended) +2. Chroot into it using the following script: +``` +#!/bin/bash + +basedir="/home/niko/chroots/arch-x86_64" +cp /etc/resolv.conf ${basedir}/etc/ +cp /usr/bin/qemu-x86_64 ${basedir}/usr/bin/ +sed -i 's!#Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$arch!Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$a> +mount --make-slave --bind ${basedir} ${basedir} +mount -t proc none ${basedir}/proc +mount -t sysfs none ${basedir}/sys/ +mount --make-rslave --rbind /dev ${basedir}/dev +mount --make-rslave --rbind /run ${basedir}/run +chroot ${basedir} /bin/bash +sleep 3 +umount -R ${basedir}/run +umount -R ${basedir}/dev +umount ${basedir}/sys +umount ${basedir}/proc +umount ${basedir} +mount | grep chroots | grep arch-x86_64 | grep -v snap +``` +3. Initialize pacaman keyring and update system: +``` +# pacman-key --init +# pacman-key --populate +# pacman -Syu +``` +4. Install android-studio from the AUR (download `PKGBUILD` and run `makepkg -s`, finally install the package with `pacman -U <packagename>`): https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=android-studio +5. Create an unpriviledged account and run `android-studio` +6. Wait for the crash. +Additional information: +``` +Wed 2023-02-15 12:39:32 CET 117922 1000 1000 SIGSEGV present /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 > +talos2 ~ # coredumpctl gdb 117922 + PID: 117922 (java) + UID: 1000 (niko) + GID: 1000 (niko) + Signal: 11 (SEGV) + Timestamp: Wed 2023-02-15 12:39:25 CET (1min 47s ago) + Command Line: /usr/bin/qemu-x86_64 /opt/android-studio/jbr/bin/java -classpath /opt/android-studio/lib/util.jar:/opt/android-studio/lib/app.jar:/opt/android-studio/lib/3rd-party-rt.jar:/opt/android-studio/lib/jna.jar:/opt/android-studio/lib/platform-statistics-devkit.jar:/opt/android-studio/lib/jps-model.jar:/opt/android-studio/lib/rd-core.jar:/opt/android-studio/lib/rd-framework.jar:/opt/android-studio/lib/stats.jar:/opt/android-studio/lib/protobuf.jar:/opt/android-studio/lib/external-system-rt.jar:/opt/android-studio/lib/forms_rt.jar:/opt/android-studio/lib/intellij-test-discovery.jar:/opt/android-studio/lib/rd-swing.jar:/opt/android-studio/lib/annotations.jar:/opt/android-studio/lib/groovy.jar:/opt/android-studio/lib/annotations-java5.jar:/opt/android-studio/lib/byte-buddy-agent.jar:/opt/android-studio/lib/error-prone-annotations.jar:/opt/android-studio/lib/externalProcess-rt.jar:/opt/android-studio/lib/grpc-netty-shaded.jar:/opt/android-studio/lib/idea_rt.jar:/opt/android-studio/lib/intellij-coverage-agent-1.0.656.jar:/opt/android-studio/lib/junit.jar:/opt/android-studio/lib/junit4.jar:/opt/android-studio/lib/lz4-java.jar:/opt/android-studio/lib/platform-objectSerializer-annotations.jar:/opt/android-studio/lib/pty4j.jar:/opt/android-studio/lib/rd-text.jar:/opt/android-studio/lib/resources.jar:/opt/android-studio/lib/util_rt.jar:/opt/android-studio/lib/winp.jar:/opt/android-studio/lib/ant/lib/ant.jar:/opt/android-studio/lib/dbus-java-3.2.1.jar:/opt/android-studio/lib/java-utils-1.0.6.jar:/opt/android-studio/lib/jnr-unixsocket-0.23.jar:/opt/android-studio/lib/jnr-ffi-2.1.10.jar:/opt/android-studio/lib/jffi-1.2.19.jar:/opt/android-studio/lib/jffi-1.2.19-native.jar:/opt/android-studio/lib/asm-7.1.jar:/opt/android-studio/lib/asm-commons-7.1.jar:/opt/android-studio/lib/asm-analysis-7.1.jar:/opt/android-studio/lib/asm-tree-7.1.jar:/opt/android-studio/lib/asm-util-7.1.jar:/opt/android-studio/lib/jnr-a64asm-1.0.0.jar:/opt/android-studio/lib/jnr-x86asm-1.0.2.jar:/opt/android-studio/lib/jnr-constants-0.9.12.jar:/opt/android-studio/lib/jnr-enxio-0.21.jar:/opt/android-studio/lib/jnr-posix-3.0.50.jar -Xms256m -Xmx1280m -XX:ReservedCodeCacheSize=512m -XX:+IgnoreUnrecognizedVMOptions -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=50 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -ea -Dsun.io.useCanonCaches=false $'-Djdk.http.auth.tunneling.disabledSchemes=""' -Djdk.attach.allowAttachSelf=true -Djdk.module.illegalAccess.silent=true -Djna.nosys=true -Djna.boot.library.path= -Didea.vendor.name=Google -Dkotlinx.coroutines.debug=off -Dsun.tools.attach.tmp.only=true -XX:ErrorFile=/home/niko/java_error_in_studio_%p.log -XX:HeapDumpPath=/home/niko/java_error_in_studio_.hprof -Djb.vmOptionsFile=/opt/android-studio/bin/studio64.vmoptions -Djava.system.class.loader=com.intellij.util.lang.PathClassLoader -Didea.strict.classpath=true -Didea.vendor.name=Google -Didea.paths.selector=AndroidStudio2022.1 -Didea.platform.prefix=AndroidStudio -Didea.jre.check=true -Dsplash=true com.intellij.idea.Main + Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 + Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Unit: user@1000.service + User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Slice: user-1000.slice + Owner UID: 1000 (niko) + Boot ID: 33cad872d21043ebbe3dd6581bdd28c6 + Machine ID: b3e834569b8ff461391f5ac061feb773 + Hostname: talos2 + Storage: /var/lib/systemd/coredump/core.java.1000.33cad872d21043ebbe3dd6581bdd28c6.117922.1676461165000000.zst (present) + Size on Disk: 226.7M + Message: Process 117922 (java) of user 1000 dumped core. + +GNU gdb (Gentoo 12.1 vanilla) 12.1 +Copyright (C) 2022 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "powerpc64le-unknown-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://bugs.gentoo.org/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64... +BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002 +BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 +BFD: warning: /var/tmp/coredump-R9M5K3: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 + +warning: Can't open file /opt/android-studio/jbr/bin/java during file-backed mapping note processing + +warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libpthread.so.0 during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/jli/libjli.so during file-backed mapping note processing + +warning: Can't open file /usr/lib/libdl.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/server/libjvm.so during file-backed mapping note processing + +warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing + +warning: Can't open file /usr/lib/librt.so.1 during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libverify.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libjava.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libjimage.so during file-backed mapping note processing + +warning: Can't open file /tmp/hsperfdata_niko/117922 during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libzip.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/modules during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libnio.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/jbr/lib/libnet.so during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/util.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/app.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/3rd-party-rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/jna.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/platform-statistics-devkit.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/jps-model.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/rd-core.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/rd-framework.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/stats.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/protobuf.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/external-system-rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/forms_rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/intellij-test-discovery.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/rd-swing.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/annotations.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/groovy.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/annotations-java5.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/byte-buddy-agent.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/error-prone-annotations.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/externalProcess-rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/grpc-netty-shaded.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/idea_rt.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/intellij-coverage-agent-1.0.656.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/junit.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/junit4.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/lz4-java.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/platform-objectSerializer-annotations.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/pty4j.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/rd-text.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/resources.jar during file-backed mapping note processing + +warning: Can't open file /opt/android-studio/lib/util_rt.jar during file-backed mapping note processing + +warning: core file may not match specified executable file. +[New LWP 117925] +[New LWP 117924] +[New LWP 117930] +[New LWP 117935] +[New LWP 117933] +[New LWP 117928] +[New LWP 117936] +[New LWP 117922] +[New LWP 117927] +[New LWP 117932] +[New LWP 117929] +[New LWP 117937] +[New LWP 117926] +[New LWP 117934] +[New LWP 117931] +[New LWP 117941] +[New LWP 117939] +[New LWP 117938] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/usr/lib64/libthread_db.so.1". +Core was generated by `/usr/bin/qemu-x86_64 /opt/android-studio/jbr/bin/java -classpath /opt/android-s'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x00000000102e1c68 in sigsuspend () +[Current thread is 1 (Thread 0x3fffbab18360 (LWP 117925))] +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x3fffbab18360 (LWP 117925) 0x00000000102e1c68 in sigsuspend () + 2 Thread 0x3fffbb3cf360 (LWP 117924) 0x000000001033afec in syscall () + 3 Thread 0x3fffba9d3360 (LWP 117930) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 4 Thread 0x3fffba951360 (LWP 117935) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 5 Thread 0x3fffba850360 (LWP 117933) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 6 Thread 0x3fffbaa55360 (LWP 117928) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 7 Thread 0x3fffba910360 (LWP 117936) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 8 Thread 0x409e2000 (LWP 117922) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 9 Thread 0x3fffbaa96360 (LWP 117927) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 10 Thread 0x3fffba891360 (LWP 117932) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 11 Thread 0x3fffbaa14360 (LWP 117929) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 12 Thread 0x3fffba60e360 (LWP 117937) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 13 Thread 0x3fffbaad7360 (LWP 117926) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 14 Thread 0x3fffba992360 (LWP 117934) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 15 Thread 0x3fffbabce360 (LWP 117931) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 16 Thread 0x3fffba7ce360 (LWP 117941) 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () + 17 Thread 0x3fffba80f360 (LWP 117939) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 18 Thread 0x3fffba5cd360 (LWP 117938) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +(gdb) thread 1 +[Switching to thread 1 (Thread 0x3fffbab18360 (LWP 117925))] +#0 0x00000000102e1c68 in sigsuspend () +(gdb) thread 2 +[Switching to thread 2 (Thread 0x3fffbb3cf360 (LWP 117924))] +#0 0x000000001033afec in syscall () +(gdb) thread 3 +[Switching to thread 3 (Thread 0x3fffba9d3360 (LWP 117930))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 4 +[Switching to thread 4 (Thread 0x3fffba951360 (LWP 117935))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 ../common-user/host/ppc64/safe-syscall.inc.S: No such file or directory. +(gdb) thread 5 +[Switching to thread 5 (Thread 0x3fffba850360 (LWP 117933))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 6 +[Switching to thread 6 (Thread 0x3fffbaa55360 (LWP 117928))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 7 +[Switching to thread 7 (Thread 0x3fffba910360 (LWP 117936))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 8 +[Switching to thread 8 (Thread 0x409e2000 (LWP 117922))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 9 +[Switching to thread 9 (Thread 0x3fffbaa96360 (LWP 117927))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 10 +[Switching to thread 10 (Thread 0x3fffba891360 (LWP 117932))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 11 +[Switching to thread 11 (Thread 0x3fffbaa14360 (LWP 117929))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 12 +[Switching to thread 12 (Thread 0x3fffba60e360 (LWP 117937))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 13 +[Switching to thread 13 (Thread 0x3fffbaad7360 (LWP 117926))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 14 +[Switching to thread 14 (Thread 0x3fffba992360 (LWP 117934))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 15 +[Switching to thread 15 (Thread 0x3fffbabce360 (LWP 117931))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 16 +[Switching to thread 16 (Thread 0x3fffba7ce360 (LWP 117941))] +#0 0x000000001037df88 in __futex_abstimed_wait_cancelable64 () +(gdb) thread 17 +[Switching to thread 17 (Thread 0x3fffba80f360 (LWP 117939))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +(gdb) thread 18 +[Switching to thread 18 (Thread 0x3fffba5cd360 (LWP 117938))] +#0 safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +75 in ../common-user/host/ppc64/safe-syscall.inc.S +``` + +Download full coredump: https://drive.google.com/file/d/1t0Tm6-O6THrOFPp8uO-pbHqv8tZ6XWUe/view?usp=share_link diff --git a/results/classifier/gemma3:12b/debug/1494 b/results/classifier/gemma3:12b/debug/1494 new file mode 100644 index 000000000..cdc4c41fd --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1494 @@ -0,0 +1,933 @@ + +[regression] [bisected] [coredump] qemu-x86_64 segfaults on ppc64le (4K page size) when downloading go dependencies: unexpected fault address 0x0 +Description of problem: +qemu-x86_64 segfaults when trying to compile yay inside an Arch Linux x86_64 chroot from a Gentoo Linux ppc64le (4K page size) host. Hardware is a Raptor CS Talos 2 Power 9. + +It works with qemu-7.2 so this is a regression in git master (or less likely with the patch). + +``` +[niko@talos2 yay]$ makepkg -s +==> Making package: yay 11.3.2-1 (Wed 15 Feb 2023 05:03:01 PM CET) +==> Checking runtime dependencies... +==> Checking buildtime dependencies... +==> Retrieving sources... + -> Found yay-11.3.2.tar.gz +==> Validating source files with sha256sums... + yay-11.3.2.tar.gz ... Passed +==> Extracting sources... + -> Extracting yay-11.3.2.tar.gz with bsdtar +==> Removing existing $pkgdir/ directory... +==> Starting build()... +go build -trimpath -mod=readonly -modcacherw -ldflags '-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay +go: downloading github.com/Jguer/votar v1.0.0 +go: downloading github.com/Jguer/aur v1.0.1 +go: downloading github.com/Jguer/go-alpm/v2 v2.1.2 +go: downloading github.com/Morganamilo/go-pacmanconf v0.0.0-20210502114700-cff030e927a5 +go: downloading golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab +go: downloading github.com/Morganamilo/go-srcinfo v1.0.0 +go: downloading golang.org/x/term v0.0.0-20220722155259-a9ba230a4035 +go: downloading github.com/leonelquinteros/gotext v1.5.0 +go: downloading github.com/adrg/strutil v0.3.0 +go: downloading golang.org/x/text v0.3.7 +make: *** [Makefile:113: yay] Illegal instruction (core dumped) +``` + +``` +[niko@talos2 yay]$ makepkg -s +==> Making package: yay 11.3.2-1 (Wed 15 Feb 2023 05:10:01 PM CET) +==> Checking runtime dependencies... +==> Checking buildtime dependencies... +==> Retrieving sources... + -> Found yay-11.3.2.tar.gz +==> Validating source files with sha256sums... + yay-11.3.2.tar.gz ... Passed +==> Extracting sources... + -> Extracting yay-11.3.2.tar.gz with bsdtar +==> Starting build()... +go build -trimpath -mod=readonly -modcacherw -ldflags '-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay +go: downloading github.com/Jguer/votar v1.0.0 +go: downloading github.com/Jguer/go-alpm/v2 v2.1.2 +go: downloading github.com/Morganamilo/go-srcinfo v1.0.0 +go: downloading github.com/Jguer/aur v1.0.1 +go: downloading github.com/leonelquinteros/gotext v1.5.0 +go: downloading github.com/Morganamilo/go-pacmanconf v0.0.0-20210502114700-cff030e927a5 +go: downloading golang.org/x/term v0.0.0-20220722155259-a9ba230a4035 +go: downloading github.com/adrg/strutil v0.3.0 +go: downloading golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab +go: downloading golang.org/x/text v0.3.7 +# math/bits +unexpected fault address 0x0 +fatal error: fault +[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0xabb70a] + +goroutine 4 [running]: +runtime.throw({0xdbf491?, 0x1?}) + /usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0001d7750 sp=0xc0001d7720 pc=0x4389fd +runtime.sigpanic() + /usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0001d77b0 sp=0xc0001d7750 pc=0x44f4ea +cmd/compile/internal/ssa.ValHeap.Less({{0xc0001ae1c0, 0x4, 0x8}, {0xc0001de700, 0x28, 0x100}}, 0x8?, 0xc0001de700?) + /usr/lib/go/src/cmd/compile/internal/ssa/schedule.go:59 +0xaa fp=0xc0001d77e0 sp=0xc0001d77b0 pc=0xabb70a +cmd/compile/internal/ssa.(*ValHeap).Less(0x4?, 0x8?, 0xc0001de700?) + <autogenerated>:1 +0x77 fp=0xc0001d7860 sp=0xc0001d77e0 pc=0xad7677 +container/heap.up({0xf24240, 0xc00019eb40}, 0xc00081b370?) + /usr/lib/go/src/container/heap/heap.go:92 +0x7e fp=0xc0001d7898 sp=0xc0001d7860 pc=0x7024de +container/heap.Push({0xf24240, 0xc00019eb40}, {0xdb1f80?, 0xc00081b370?}) + /usr/lib/go/src/container/heap/heap.go:53 +0x5a fp=0xc0001d78c0 sp=0xc0001d7898 pc=0x7022da +cmd/compile/internal/ssa.schedule(0xc0004ea000) + /usr/lib/go/src/cmd/compile/internal/ssa/schedule.go:349 +0x151c fp=0xc0001d7eb0 sp=0xc0001d78c0 pc=0xabcd9c +cmd/compile/internal/ssa.Compile(0xc0004ea000) + /usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0001dbb68 sp=0xc0001d7eb0 pc=0x76bc43 +cmd/compile/internal/ssagen.buildssa(0xc00071b540, 0x2) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0001dbea8 sp=0xc0001dbb68 pc=0xaf0527 +cmd/compile/internal/ssagen.Compile(0xc00071b540, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0001dbf70 sp=0xc0001dbea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0001dbfb0 sp=0xc0001dbf70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0001dbfe0 sp=0xc0001dbfb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0001dbfe8 sp=0xc0001dbfe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 1 [semacquire]: +runtime.gopark(0xc0000062e8?, 0xc00019a050?, 0x0?, 0xa0?, 0x4027dba128?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0005ad968 sp=0xc0005ad948 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.semacquire1(0xc0008c4768, 0x20?, 0x1, 0x0, 0x0?) + /usr/lib/go/src/runtime/sema.go:160 +0x20f fp=0xc0005ad9d0 sp=0xc0005ad968 pc=0x44c9af +sync.runtime_Semacquire(0xc0008b8000?) + /usr/lib/go/src/runtime/sema.go:62 +0x27 fp=0xc0005ada08 sp=0xc0005ad9d0 pc=0x46a6e7 +sync.(*WaitGroup).Wait(0xc000659800?) + /usr/lib/go/src/sync/waitgroup.go:116 +0x4b fp=0xc0005ada30 sp=0xc0005ada08 pc=0x487deb +cmd/compile/internal/gc.compileFunctions() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:183 +0x235 fp=0xc0005ada88 sp=0xc0005ada30 pc=0xcc6675 +cmd/compile/internal/gc.Main(0xdf8e28) + /usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc0005adf20 sp=0xc0005ada88 pc=0xcc86aa +main.main() + /usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc0005adf80 sp=0xc0005adf20 pc=0xcf00bd +runtime.main() + /usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc0005adfe0 sp=0xc0005adf80 pc=0x43b2e7 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0005adfe8 sp=0xc0005adfe0 pc=0x46e201 + +goroutine 2 [force gc (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009afb0 sp=0xc00009af90 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.forcegchelper() + /usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009afe0 sp=0xc00009afb0 pc=0x43b550 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009afe8 sp=0xc00009afe0 pc=0x46e201 +created by runtime.init.6 + /usr/lib/go/src/runtime/proc.go:293 +0x25 + +goroutine 17 [GC sweep wait]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000096780 sp=0xc000096760 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.bgsweep(0x0?) + /usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc0000967c8 sp=0xc000096780 pc=0x425cce +runtime.gcenable.func1() + /usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc0000967e0 sp=0xc0000967c8 pc=0x41aee6 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000967e8 sp=0xc0000967e0 pc=0x46e201 +created by runtime.gcenable + /usr/lib/go/src/runtime/mgc.go:178 +0x6b + +goroutine 18 [GC scavenge wait]: +runtime.gopark(0xc000194000?, 0xf1ad58?, 0x1?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000096f70 sp=0xc000096f50 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.(*scavengerState).park(0x1487ce0) + /usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc000096fa0 sp=0xc000096f70 pc=0x423c13 +runtime.bgscavenge(0x0?) + /usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc000096fc8 sp=0xc000096fa0 pc=0x4241e5 +runtime.gcenable.func2() + /usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc000096fe0 sp=0xc000096fc8 pc=0x41ae86 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000096fe8 sp=0xc000096fe0 pc=0x46e201 +created by runtime.gcenable + /usr/lib/go/src/runtime/mgc.go:179 +0xaa + +goroutine 33 [finalizer wait]: +runtime.gopark(0x43ba92?, 0x4027cf9f48?, 0x0?, 0x0?, 0xc00009a770?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009a628 sp=0xc00009a608 pc=0x43b716 +runtime.runfinq() + /usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009a7e0 sp=0xc00009a628 pc=0x419f27 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009a7e8 sp=0xc00009a7e0 pc=0x46e201 +created by runtime.createfing + /usr/lib/go/src/runtime/mfinal.go:163 +0x45 + +goroutine 49 [select]: +runtime.gopark(0xc0004e6fb0?, 0x2?, 0xf0?, 0x6d?, 0xc0004e6f6c?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0004e6da0 sp=0xc0004e6d80 pc=0x43b716 +runtime.selectgo(0xc0004e6fb0, 0xc0004e6f68, 0xc000504000?, 0x0, 0xd26040?, 0x1) + /usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc0004e6ee0 sp=0xc0004e6da0 pc=0x44b8be +cmd/compile/internal/gc.compileFunctions.func3() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc0004e6fe0 sp=0xc0004e6ee0 pc=0xcc6a12 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004e6fe8 sp=0xc0004e6fe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8 + +goroutine 3 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0004f7858 sp=0xc0004f7838 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0004f79e0 sp=0xc0004f7858 pc=0x46f85b +cmd/compile/internal/ssa.is64BitInt(0xc000141480) + /usr/lib/go/src/cmd/compile/internal/ssa/rewrite.go:218 +0xa fp=0xc0004f79e8 sp=0xc0004f79e0 pc=0x7e2e8a +cmd/compile/internal/ssa.rewriteValueAMD64_OpLoad(0xc00086a458) + /usr/lib/go/src/cmd/compile/internal/ssa/rewriteAMD64.go:29312 +0x51 fp=0xc0004f7a28 sp=0xc0004f79e8 pc=0x884911 +cmd/compile/internal/ssa.rewriteValueAMD64(0xc00089f678?) + /usr/lib/go/src/cmd/compile/internal/ssa/rewriteAMD64.go:838 +0x31be fp=0xc0004f7a48 sp=0xc0004f7a28 pc=0x819bbe +cmd/compile/internal/ssa.applyRewrite(0xc0001b2000, 0xdf92a8, 0xdf9348, 0x1) + /usr/lib/go/src/cmd/compile/internal/ssa/rewrite.go:133 +0x1016 fp=0xc0004f7e80 sp=0xc0004f7a48 pc=0x7e27d6 +cmd/compile/internal/ssa.lower(0xc0001b2000?) + /usr/lib/go/src/cmd/compile/internal/ssa/lower.go:10 +0x2f fp=0xc0004f7eb0 sp=0xc0004f7e80 pc=0x7b4c4f +cmd/compile/internal/ssa.Compile(0xc0001b2000) + /usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0004fbb68 sp=0xc0004f7eb0 pc=0x76bc43 +cmd/compile/internal/ssagen.buildssa(0xc00071b900, 0x3) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0004fbea8 sp=0xc0004fbb68 pc=0xaf0527 +cmd/compile/internal/ssagen.Compile(0xc00071b900, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0004fbf70 sp=0xc0004fbea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0004fbfb0 sp=0xc0004fbf70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0004fbfe0 sp=0xc0004fbfb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004fbfe8 sp=0xc0004fbfe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 50 [runnable]: +cmd/compile/internal/ssa.(*Value).clobbersFlags(0xc0007ce6d8?) + /usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:243 +0xd5 fp=0xc0000dbbf0 sp=0xc0000dbbe8 pc=0x79c375 +cmd/compile/internal/ssa.flagalloc(0xc0000ca000) + /usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:39 +0x172a fp=0xc0000dbeb0 sp=0xc0000dbbf0 pc=0x79c0ca +cmd/compile/internal/ssa.Compile(0xc0000ca000) + /usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0000dfb68 sp=0xc0000dbeb0 pc=0x76bc43 +cmd/compile/internal/ssagen.buildssa(0xc00071ba40, 0x1) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0000dfea8 sp=0xc0000dfb68 pc=0xaf0527 +cmd/compile/internal/ssagen.Compile(0xc00071ba40, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000dff70 sp=0xc0000dfea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000dffb0 sp=0xc0000dff70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000dffe0 sp=0xc0000dffb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000dffe8 sp=0xc0000dffe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 51 [runnable]: +cmd/compile/internal/ssa.(*Value).clobbersFlags(0xc000780d90?) + /usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:243 +0xd5 fp=0xc00091bbf0 sp=0xc00091bbe8 pc=0x79c375 +cmd/compile/internal/ssa.flagalloc(0xc000774540) + /usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:39 +0x172a fp=0xc00091beb0 sp=0xc00091bbf0 pc=0x79c0ca +cmd/compile/internal/ssa.Compile(0xc000774540) + /usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc00091fb68 sp=0xc00091beb0 pc=0x76bc43 +cmd/compile/internal/ssagen.buildssa(0xc000703900, 0x0) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc00091fea8 sp=0xc00091fb68 pc=0xaf0527 +cmd/compile/internal/ssagen.Compile(0xc000703900, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc00091ff70 sp=0xc00091fea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc00091ffb0 sp=0xc00091ff70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc00091ffe0 sp=0xc00091ffb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00091ffe8 sp=0xc00091ffe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 +# unicode/utf8 +unexpected fault address 0x0 +fatal error: fault +[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x411410] + +goroutine 19 [running]: +runtime.throw({0xdbf491?, 0x4000804d28?}) + /usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0004f1830 sp=0xc0004f1800 pc=0x4389fd +runtime.sigpanic() + /usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0004f1890 sp=0xc0004f1830 pc=0x44f4ea +runtime.mapaccess2_fast32(0xc0009b3c00, 0xc000562000, 0x6be729) + /usr/lib/go/src/runtime/map_fast32.go:53 +0x170 fp=0xc0004f1898 sp=0xc0004f1890 pc=0x411410 +cmd/compile/internal/ssagen.genssa(0xc000562000, 0xc000988ee0) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:6964 +0x965 fp=0xc0004f1ea8 sp=0xc0004f1898 pc=0xb27345 +cmd/compile/internal/ssagen.Compile(0xc0000fcb40, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0004f1f70 sp=0xc0004f1ea8 pc=0xae7b8f +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0004f1fb0 sp=0xc0004f1f70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0004f1fe0 sp=0xc0004f1fb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004f1fe8 sp=0xc0004f1fe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 1 [semacquire]: +runtime.gopark(0x20?, 0xd7ca20?, 0x0?, 0x60?, 0xc00003a600?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0005a9968 sp=0xc0005a9948 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.semacquire1(0xc0006d5a88, 0x20?, 0x1, 0x0, 0x0?) + /usr/lib/go/src/runtime/sema.go:160 +0x20f fp=0xc0005a99d0 sp=0xc0005a9968 pc=0x44c9af +sync.runtime_Semacquire(0xc0000fdb80?) + /usr/lib/go/src/runtime/sema.go:62 +0x27 fp=0xc0005a9a08 sp=0xc0005a99d0 pc=0x46a6e7 +sync.(*WaitGroup).Wait(0xc0008ca400?) + /usr/lib/go/src/sync/waitgroup.go:116 +0x4b fp=0xc0005a9a30 sp=0xc0005a9a08 pc=0x487deb +cmd/compile/internal/gc.compileFunctions() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:183 +0x235 fp=0xc0005a9a88 sp=0xc0005a9a30 pc=0xcc6675 +cmd/compile/internal/gc.Main(0xdf8e28) + /usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc0005a9f20 sp=0xc0005a9a88 pc=0xcc86aa +main.main() + /usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc0005a9f80 sp=0xc0005a9f20 pc=0xcf00bd +runtime.main() + /usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc0005a9fe0 sp=0xc0005a9f80 pc=0x43b2e7 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0005a9fe8 sp=0xc0005a9fe0 pc=0x46e201 + +goroutine 2 [force gc (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009cfb0 sp=0xc00009cf90 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.forcegchelper() + /usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009cfe0 sp=0xc00009cfb0 pc=0x43b550 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009cfe8 sp=0xc00009cfe0 pc=0x46e201 +created by runtime.init.6 + /usr/lib/go/src/runtime/proc.go:293 +0x25 + +goroutine 3 [GC sweep wait]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009d780 sp=0xc00009d760 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.bgsweep(0x0?) + /usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00009d7c8 sp=0xc00009d780 pc=0x425cce +runtime.gcenable.func1() + /usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc00009d7e0 sp=0xc00009d7c8 pc=0x41aee6 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009d7e8 sp=0xc00009d7e0 pc=0x46e201 +created by runtime.gcenable + /usr/lib/go/src/runtime/mgc.go:178 +0x6b + +goroutine 4 [GC scavenge wait]: +runtime.gopark(0xc0000380e0?, 0xf1ad58?, 0x1?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009df70 sp=0xc00009df50 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.(*scavengerState).park(0x1487ce0) + /usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc00009dfa0 sp=0xc00009df70 pc=0x423c13 +runtime.bgscavenge(0x0?) + /usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc00009dfc8 sp=0xc00009dfa0 pc=0x4241e5 +runtime.gcenable.func2() + /usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc00009dfe0 sp=0xc00009dfc8 pc=0x41ae86 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009dfe8 sp=0xc00009dfe0 pc=0x46e201 +created by runtime.gcenable + /usr/lib/go/src/runtime/mgc.go:179 +0xaa + +goroutine 17 [finalizer wait]: +runtime.gopark(0x43ba92?, 0x4027cf9fe8?, 0x0?, 0x0?, 0xc00009c770?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009c628 sp=0xc00009c608 pc=0x43b716 +runtime.runfinq() + /usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009c7e0 sp=0xc00009c628 pc=0x419f27 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009c7e8 sp=0xc00009c7e0 pc=0x46e201 +created by runtime.createfing + /usr/lib/go/src/runtime/mfinal.go:163 +0x45 + +goroutine 49 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0009c1308 sp=0xc0009c12e8 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0009c1490 sp=0xc0009c1308 pc=0x46f85b +cmd/compile/internal/ssa.PopulateABIInRegArgOps(0xc000754700) + /usr/lib/go/src/cmd/compile/internal/ssa/debug.go:436 +0x57 fp=0xc0009c16f0 sp=0xc0009c1490 pc=0x779bb7 +cmd/compile/internal/ssa.BuildFuncDebug(0xc00041e5a0?, 0xc000754700, 0xc000000049?, 0xa?, 0xc00098c000) + /usr/lib/go/src/cmd/compile/internal/ssa/debug.go:578 +0x1d6 fp=0xc0009c1898 sp=0xc0009c16f0 pc=0x77adb6 +cmd/compile/internal/ssagen.genssa(0xc000754700, 0xc0004bfce0) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7157 +0xf2b fp=0xc0009c1ea8 sp=0xc0009c1898 pc=0xb2790b +cmd/compile/internal/ssagen.Compile(0xc0000fc8c0, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0009c1f70 sp=0xc0009c1ea8 pc=0xae7b8f +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0009c1fb0 sp=0xc0009c1f70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0009c1fe0 sp=0xc0009c1fb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0009c1fe8 sp=0xc0009c1fe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 5 [select]: +runtime.gopark(0xc00009e7b0?, 0x2?, 0xf0?, 0xe5?, 0xc00009e76c?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009e5a0 sp=0xc00009e580 pc=0x43b716 +runtime.selectgo(0xc00009e7b0, 0xc00009e768, 0x0?, 0x0, 0xd26040?, 0x1) + /usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc00009e6e0 sp=0xc00009e5a0 pc=0x44b8be +cmd/compile/internal/gc.compileFunctions.func3() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc00009e7e0 sp=0xc00009e6e0 pc=0xcc6a12 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009e7e8 sp=0xc00009e7e0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8 + +goroutine 50 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0001cd308 sp=0xc0001cd2e8 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0001cd490 sp=0xc0001cd308 pc=0x46f85b +cmd/compile/internal/ssa.PopulateABIInRegArgOps(0xc000192000) + /usr/lib/go/src/cmd/compile/internal/ssa/debug.go:436 +0x57 fp=0xc0001cd6f0 sp=0xc0001cd490 pc=0x779bb7 +cmd/compile/internal/ssa.BuildFuncDebug(0xc0001a65a0?, 0xc000192000, 0xc000000049?, 0x12?, 0xc0001a4000) + /usr/lib/go/src/cmd/compile/internal/ssa/debug.go:578 +0x1d6 fp=0xc0001cd898 sp=0xc0001cd6f0 pc=0x77adb6 +cmd/compile/internal/ssagen.genssa(0xc000192000, 0xc00019f260) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7157 +0xf2b fp=0xc0001cdea8 sp=0xc0001cd898 pc=0xb2790b +cmd/compile/internal/ssagen.Compile(0xc0000fca00, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0001cdf70 sp=0xc0001cdea8 pc=0xae7b8f +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0001cdfb0 sp=0xc0001cdf70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0001cdfe0 sp=0xc0001cdfb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0001cdfe8 sp=0xc0001cdfe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 20 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0008e10f8 sp=0xc0008e10d8 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0008e1280 sp=0xc0008e10f8 pc=0x46f85b +cmd/compile/internal/ssagen.AddrAuto(0xc000201ed0, 0x81308171a15?) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7649 +0x94 fp=0xc0008e12a8 sp=0xc0008e1280 pc=0xb2d9d4 +cmd/compile/internal/amd64.ssaGenValue(0xc0008bec60, 0xc000781ab0) + /usr/lib/go/src/cmd/compile/internal/amd64/ssa.go:1037 +0x13dc fp=0xc0008e1898 sp=0xc0008e12a8 pc=0xb3d6bc +cmd/compile/internal/ssagen.genssa(0xc0004e4000, 0xc0008e8070) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7024 +0x3ff8 fp=0xc0008e1ea8 sp=0xc0008e1898 pc=0xb2a9d8 +cmd/compile/internal/ssagen.Compile(0xc0000fcc80, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0008e1f70 sp=0xc0008e1ea8 pc=0xae7b8f +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0008e1fb0 sp=0xc0008e1f70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0008e1fe0 sp=0xc0008e1fb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0008e1fe8 sp=0xc0008e1fe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 +# internal/reflectlite +unexpected fault address 0x0 +fatal error: fault +[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x66b360] + +goroutine 6 [running]: +runtime.throw({0xdbf491?, 0x8?}) + /usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0000dc720 sp=0xc0000dc6f0 pc=0x4389fd +runtime.sigpanic() + /usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0000dc780 sp=0xc0000dc720 pc=0x44f4ea +cmd/compile/internal/abi.(*assignState).regAllocate(0xc0000dc7a0, 0x41b2b1, {0x14cdd40, 0xc0000dc808}, 0xa8) + /usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:607 fp=0xc0000dc788 sp=0xc0000dc780 pc=0x66b360 +cmd/compile/internal/abi.(*assignState).assignParamOrReturn(0xc0000dc8a8, 0xc0008977a0, {0xf23198, 0xc000a0b080}, 0x20?) + /usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:777 +0x165 fp=0xc0000dc840 sp=0xc0000dc788 pc=0x66bae5 +cmd/compile/internal/abi.(*ABIConfig).ABIAnalyzeFuncType(0xc0000bca60, 0xc00089b710) + /usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:404 +0x3d7 fp=0xc0000dc9f8 sp=0xc0000dc840 pc=0x669a17 +cmd/compile/internal/abi.(*ABIConfig).ABIAnalyze(0xd41a80?, 0xc0000d0600?, 0x0?) + /usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:432 +0x5d fp=0xc0000dcb68 sp=0xc0000dc9f8 pc=0x669e7d +cmd/compile/internal/ssagen.buildssa(0xc0008cc500, 0x1) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:455 +0x1209 fp=0xc0000dcea8 sp=0xc0000dcb68 pc=0xaef709 +cmd/compile/internal/ssagen.Compile(0xc0008cc500, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000dcf70 sp=0xc0000dcea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000dcfb0 sp=0xc0000dcf70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000dcfe0 sp=0xc0000dcfb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000dcfe8 sp=0xc0000dcfe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 1 [runnable]: +runtime.gopark(0xc0000be000?, 0xc0004edec0?, 0xb0?, 0x99?, 0xc000739978?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000739910 sp=0xc0007398f0 pc=0x43b716 +runtime.chansend(0xc000d540c0, 0xc0007399e8, 0x1, 0xc0007399d8?) + /usr/lib/go/src/runtime/chan.go:259 +0x42e fp=0xc000739998 sp=0xc000739910 pc=0x40602e +runtime.chansend1(0xd7ca20?, 0x4000803501?) + /usr/lib/go/src/runtime/chan.go:145 +0x1d fp=0xc0007399c8 sp=0xc000739998 pc=0x405bdd +cmd/compile/internal/gc.compileFunctions.func4(0xc00180cc40) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:160 +0x27 fp=0xc0007399e8 sp=0xc0007399c8 pc=0xcc68a7 +cmd/compile/internal/gc.compileFunctions.func5({0xc001099500, 0x222, 0x350?}) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:170 +0x53 fp=0xc000739a30 sp=0xc0007399e8 pc=0xcc6713 +cmd/compile/internal/gc.compileFunctions() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:181 +0x1ff fp=0xc000739a88 sp=0xc000739a30 pc=0xcc663f +cmd/compile/internal/gc.Main(0xdf8e28) + /usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc000739f20 sp=0xc000739a88 pc=0xcc86aa +main.main() + /usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc000739f80 sp=0xc000739f20 pc=0xcf00bd +runtime.main() + /usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc000739fe0 sp=0xc000739f80 pc=0x43b2e7 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000739fe8 sp=0xc000739fe0 pc=0x46e201 + +goroutine 2 [force gc (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009cfb0 sp=0xc00009cf90 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.forcegchelper() + /usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009cfe0 sp=0xc00009cfb0 pc=0x43b550 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009cfe8 sp=0xc00009cfe0 pc=0x46e201 +created by runtime.init.6 + /usr/lib/go/src/runtime/proc.go:293 +0x25 + +goroutine 3 [GC sweep wait]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009d780 sp=0xc00009d760 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.bgsweep(0x0?) + /usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00009d7c8 sp=0xc00009d780 pc=0x425cce +runtime.gcenable.func1() + /usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc00009d7e0 sp=0xc00009d7c8 pc=0x41aee6 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009d7e8 sp=0xc00009d7e0 pc=0x46e201 +created by runtime.gcenable + /usr/lib/go/src/runtime/mgc.go:178 +0x6b + +goroutine 4 [GC scavenge wait]: +runtime.gopark(0xc0000380e0?, 0xf1ad58?, 0x1?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009df70 sp=0xc00009df50 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.(*scavengerState).park(0x1487ce0) + /usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc00009dfa0 sp=0xc00009df70 pc=0x423c13 +runtime.bgscavenge(0x0?) + /usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc00009dfc8 sp=0xc00009dfa0 pc=0x4241e5 +runtime.gcenable.func2() + /usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc00009dfe0 sp=0xc00009dfc8 pc=0x41ae86 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009dfe8 sp=0xc00009dfe0 pc=0x46e201 +created by runtime.gcenable + /usr/lib/go/src/runtime/mgc.go:179 +0xaa + +goroutine 17 [finalizer wait]: +runtime.gopark(0x43ba92?, 0x4027d38828?, 0x0?, 0x0?, 0xc00009c770?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009c628 sp=0xc00009c608 pc=0x43b716 +runtime.runfinq() + /usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009c7e0 sp=0xc00009c628 pc=0x419f27 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009c7e8 sp=0xc00009c7e0 pc=0x46e201 +created by runtime.createfing + /usr/lib/go/src/runtime/mfinal.go:163 +0x45 + +goroutine 5 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc000194658 sp=0xc000194638 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0001947e0 sp=0xc000194658 pc=0x46f85b +cmd/compile/internal/ssagen.(*state).stmt(0xc0001fe500, {0xf2a400, 0xc000a990a0?}) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1432 +0xbb fp=0xc000194b68 sp=0xc0001947e0 pc=0xaf509b +cmd/compile/internal/ssagen.(*state).stmtList(...) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 +cmd/compile/internal/ssagen.buildssa(0xc0005d9540, 0x2) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc000194ea8 sp=0xc000194b68 pc=0xaf03e6 +cmd/compile/internal/ssagen.Compile(0xc0005d9540, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc000194f70 sp=0xc000194ea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc000194fb0 sp=0xc000194f70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc000194fe0 sp=0xc000194fb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000194fe8 sp=0xc000194fe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 33 [select]: +runtime.gopark(0xc0000997b0?, 0x2?, 0xf0?, 0x95?, 0xc00009976c?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0000995a0 sp=0xc000099580 pc=0x43b716 +runtime.selectgo(0xc0000997b0, 0xc000099768, 0xc000110000?, 0x0, 0xd26040?, 0x1) + /usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc0000996e0 sp=0xc0000995a0 pc=0x44b8be +cmd/compile/internal/gc.compileFunctions.func3() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc0000997e0 sp=0xc0000996e0 pc=0xcc6a12 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000997e8 sp=0xc0000997e0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8 + +goroutine 22 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0000ad2d0 sp=0xc0000ad2b0 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0000ad458 sp=0xc0000ad2d0 pc=0x46f85b +cmd/compile/internal/ssagen.(*state).stmt(0xc0016ada00, {0xf295c0, 0xc00134d450?}) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1455 +0x19a fp=0xc0000ad7e0 sp=0xc0000ad458 pc=0xaf517a +cmd/compile/internal/ssagen.(*state).stmtList(...) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 +cmd/compile/internal/ssagen.(*state).stmt(0xc0016ada00, {0xf29800, 0xc0013eebc0?}) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1441 +0x45e5 fp=0xc0000adb68 sp=0xc0000ad7e0 pc=0xaf95c5 +cmd/compile/internal/ssagen.(*state).stmtList(...) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 +cmd/compile/internal/ssagen.buildssa(0xc0005d8b40, 0x3) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc0000adea8 sp=0xc0000adb68 pc=0xaf03e6 +cmd/compile/internal/ssagen.Compile(0xc0005d8b40, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000adf70 sp=0xc0000adea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000adfb0 sp=0xc0000adf70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000adfe0 sp=0xc0000adfb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000adfe8 sp=0xc0000adfe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 49 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0017932d0 sp=0xc0017932b0 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc001793458 sp=0xc0017932d0 pc=0x46f85b +cmd/compile/internal/ssagen.(*state).stmt(0xc001794000, {0xf295c0, 0xc00140a960?}) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1455 +0x19a fp=0xc0017937e0 sp=0xc001793458 pc=0xaf517a +cmd/compile/internal/ssagen.(*state).stmtList(...) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 +cmd/compile/internal/ssagen.(*state).stmt(0xc001794000, {0xf2a400, 0xc000a92a10?}) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1436 +0x150 fp=0xc001793b68 sp=0xc0017937e0 pc=0xaf5130 +cmd/compile/internal/ssagen.(*state).stmtList(...) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 +cmd/compile/internal/ssagen.buildssa(0xc0005d9680, 0x0) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc001793ea8 sp=0xc001793b68 pc=0xaf03e6 +cmd/compile/internal/ssagen.Compile(0xc0005d9680, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc001793f70 sp=0xc001793ea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc001793fb0 sp=0xc001793f70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc001793fe0 sp=0xc001793fb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc001793fe8 sp=0xc001793fe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 +``` +Steps to reproduce: +1. Create an Arch Linux chroot from a bootstrap tarball: https://wiki.archlinux.org/title/Install_Arch_Linux_from_existing_Linux#Method_A:_Using_the_bootstrap_tarball_(recommended) +2. Chroot into it using the following script: +``` +#!/bin/bash + +basedir="/home/niko/chroots/arch-x86_64" +cp /etc/resolv.conf ${basedir}/etc/ +cp /usr/bin/qemu-x86_64 ${basedir}/usr/bin/ +sed -i 's!#Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$arch!Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$a> +mount --make-slave --bind ${basedir} ${basedir} +mount -t proc none ${basedir}/proc +mount -t sysfs none ${basedir}/sys/ +mount --make-rslave --rbind /dev ${basedir}/dev +mount --make-rslave --rbind /run ${basedir}/run +chroot ${basedir} /bin/bash +sleep 3 +umount -R ${basedir}/run +umount -R ${basedir}/dev +umount ${basedir}/sys +umount ${basedir}/proc +umount ${basedir} +mount | grep chroots | grep arch-x86_64 | grep -v snap +``` +3. Initialize pacaman keyring and update system: +``` +# pacman-key --init +# pacman-key --populate +# pacman -Syu +``` +4. Download the yay `PKGBUILD` from the AUR (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=yay) and run `makepkg -s` +5. Wait for the crash. +Additional information: +``` +Wed 2023-02-15 17:03:22 CET 495600 1000 1000 SIGILL present /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 > +Wed 2023-02-15 17:11:25 CET 509058 1000 1000 SIGSEGV present /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 > +talos2 ~ # coredumpctl gdb 495600 + PID: 495600 (go) + UID: 1000 (niko) + GID: 1000 (niko) + Signal: 4 (ILL) + Timestamp: Wed 2023-02-15 17:03:21 CET (13min ago) + Command Line: /usr/bin/qemu-x86_64 /usr/bin/go build -trimpath -mod=readonly -modcacherw -ldflags $'-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay + Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 + Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Unit: user@1000.service + User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Slice: user-1000.slice + Owner UID: 1000 (niko) + Boot ID: 33cad872d21043ebbe3dd6581bdd28c6 + Machine ID: b3e834569b8ff461391f5ac061feb773 + Hostname: talos2 + Storage: /var/lib/systemd/coredump/core.go.1000.33cad872d21043ebbe3dd6581bdd28c6.495600.1676477001000000.zst (present) + Size on Disk: 7.4M + Message: Process 495600 (go) of user 1000 dumped core. + +GNU gdb (Gentoo 12.1 vanilla) 12.1 +Copyright (C) 2022 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "powerpc64le-unknown-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://bugs.gentoo.org/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64... +BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002 +BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 +BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 + +warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libresolv.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/f2/f2133743f1bb49d82c152c57fea6c71755a865029a19ff845dd27e420f5fa0be-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/89/89e115246dee235465b64002c5ab8a7df3a3f1b776d78dab9cd937c4892860a0-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/79/791d1887c70eed91dc52577c14310590649cb307ef557d46d8cc10df4704a957-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/86/86d5a3a0121a98ed0805aa57bc14d0bd85178c04054816d99495336d86c5bf5f-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/31/31d19f3051c8985f29f85ea43d9445e4b848c58a17a79d4e726280a9bced5743-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/79/79d75d9215f18cbef6b6a66468f78efd92edc13f7093f600b1552032732410aa-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/bc/bcdca8f344789eb190a1124fe919aa975d08f07250bfc6d780b0ae0cc28092fe-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/86/86e73e7b053ab6e1e1d149b5d1bbba621bfc3d0bbc66ec6310c072c82a7221e7-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/b1/b12eb8399331175352cb92b971280ba5c0c501c6ffa5c330921c3c0667c5f199-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/32/3264d3f95a5e2e731c952060b0cd4cb3bc37ff884513397336d40c935d098e5b-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/19/1977592d2d60e1dd1025609428d04f6cc17283759aae0c97bd8f35e8a341679b-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/a9/a9b261a012c19401c1fd78154a20f58bb7778e731e17f903eb3fe8ed3a5ddd59-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/96/9697f94a563c1bd04db2a82ac1770821f97548911f616dd1149bb87d0f48d65b-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/56/56e54c1dc0b6bee517915ce0bdf694a3b94f4de88b2cabb987b645e1255594fb-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/7e/7e9d9d14f25fe76951999c17680e09a181c5f14c9c4f30fe6bff8d0d669590c3-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/f4/f431652315a861a2a85b47ae12cfc99734b3db4754aa35c9158254e4ba3507c0-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/1c/1c51052ad1af6b1a1575f9bbc3f4616ed673578a285ae9a29f5548eed68c05dd-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/be/be3037525f021f1d7e2e8499d3dcc0f44be39adf70eb91979c96db3e5645bcf1-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/55/557fa6c4030abc2d7b6407ce3093ae5772939f1a2595be09dd670ecd1c5ec8f2-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/69/69a73f1b9f395cf4a1666dde8d7971a0bd9313fbfa55a5109eb02e59b301be09-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/ab/abc0750a5bd45b2346aa5bc87092f67207e9436307e3e32cb470952f87d13fb6-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/da/dadc71547f56ab68eccefd0d571599f99739a3d75acc444d97829d6ab62a6922-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/91/915619420aacc3b5964e7537365661258ab52ec44fb7ab29790258822c793de5-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/68/6834d594cb4ffe53979a0c4611bb5200e6e0c580acb42f4383ed2fb6a93d758d-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/c6/c6ccbc76ef432925fc1a5ea22ab750ac591f3e8983d2f33f54b01c799e3a274d-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/89/893c62418d079bf692b5ff17db226ae3d0fefdc87cbd0c64f30c437677a288ec-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/d8/d8666c5d7807c5a08b30f2278a1efd691c188804b3090704bd0b3f8ef06c40d9-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/d4/d401ca16783c19ff776f35305023173b63e2610e313b9a793734af80afda4e83-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/d0/d0593989dbf79e26b8bf6705325c6b44044e560a22c3ab81d320c67dcd97f1eb-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/57/572953ae015634b922f88b0191804a949206100adb6bd2454db615e2774dbe30-d during file-backed mapping note processing + +warning: Can't open file /usr/lib/libnss_mymachines.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libcap.so.2.67 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libgcc_s.so.1 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libnss_resolve.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libnss_myhostname.so.2 during file-backed mapping note processing + +warning: core file may not match specified executable file. +[New LWP 495627] +[New LWP 495604] +[New LWP 495603] +[New LWP 495614] +[New LWP 495602] +[New LWP 495610] +[New LWP 495618] +[New LWP 495606] +[New LWP 495621] +[New LWP 495608] +[New LWP 495612] +[New LWP 495629] +[New LWP 495615] +[New LWP 495622] +[New LWP 495600] +[New LWP 495605] +[New LWP 495623] +[New LWP 495630] +[New LWP 495616] +[New LWP 495633] +[New LWP 495634] +[New LWP 495635] +[New LWP 495636] +[New LWP 495637] +[New LWP 495632] +[New LWP 495609] +[New LWP 495620] +[New LWP 495617] +[New LWP 495624] +[New LWP 495628] +[New LWP 495625] +[New LWP 495607] +[New LWP 495613] +[New LWP 495626] +[New LWP 495619] +[New LWP 495611] +[New LWP 495631] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/usr/lib64/libthread_db.so.1". +Core was generated by `/usr/bin/qemu-x86_64 /usr/bin/go build -trimpath -mod=readonly -modcacherw -ldf'. +Program terminated with signal SIGILL, Illegal instruction. +#0 0x00003fff9d5d7284 in code_gen_buffer () +[Current thread is 1 (Thread 0x3fff4bf3c380 (LWP 495627))] +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x3fff4bf3c380 (LWP 495627) 0x00003fff9d5d7284 in code_gen_buffer () + 2 Thread 0x3fffa85ec380 (LWP 495604) 0x000000001029ba2c in __lll_lock_wait () + 3 Thread 0x3fffa862d380 (LWP 495603) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 4 Thread 0x3fffa8362380 (LWP 495614) 0x00000000100ef210 in tb_jmp_cache_get_tb (hash=3271, jc=0x3fff6c00c5c0) + at ../accel/tcg/tb-jmp-cache.h:38 + 5 Thread 0x3fffa8eaf380 (LWP 495602) 0x00000000102cf6ec in syscall () + 6 Thread 0x3fffa8466380 (LWP 495610) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 7 Thread 0x3fffa815d380 (LWP 495618) 0x00000000101e07c8 in g_hash_table_lookup () + 8 Thread 0x3fffa856a380 (LWP 495606) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 9 Thread 0x3fffa809a380 (LWP 495621) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 10 Thread 0x3fffa84e8380 (LWP 495608) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 11 Thread 0x3fffa83e4380 (LWP 495612) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 12 Thread 0x3fff4beba380 (LWP 495629) 0x00003fff9c1c84b8 in code_gen_buffer () + 13 Thread 0x3fffa8321380 (LWP 495615) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 14 Thread 0x3fffa86ae380 (LWP 495622) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 15 Thread 0x200f4000 (LWP 495600) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 16 Thread 0x3fffa85ab380 (LWP 495605) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 17 Thread 0x3fffa8059380 (LWP 495623) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 18 Thread 0x3fff4be79380 (LWP 495630) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 19 Thread 0x3fffa82e0380 (LWP 495616) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 20 Thread 0x3fff4bdb6380 (LWP 495633) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 21 Thread 0x3fff4bd75380 (LWP 495634) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 22 Thread 0x3fff4bd34380 (LWP 495635) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 23 Thread 0x3fff4bcf3380 (LWP 495636) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 24 Thread 0x3fff4bcb2380 (LWP 495637) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 25 Thread 0x3fff4bdf7380 (LWP 495632) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 26 Thread 0x3fffa84a7380 (LWP 495609) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 27 Thread 0x3fffa80db380 (LWP 495620) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 28 Thread 0x3fffa829f380 (LWP 495617) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 29 Thread 0x3fff4bfff380 (LWP 495624) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 30 Thread 0x3fff4befb380 (LWP 495628) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 31 Thread 0x3fff4bfbe380 (LWP 495625) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 32 Thread 0x3fffa8529380 (LWP 495607) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 33 Thread 0x3fffa83a3380 (LWP 495613) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 34 Thread 0x3fff4bf7d380 (LWP 495626) 0x00003fff9d5d7284 in code_gen_buffer () + 35 Thread 0x3fffa811c380 (LWP 495619) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 36 Thread 0x3fffa8425380 (LWP 495611) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 37 Thread 0x3fff4be38380 (LWP 495631) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +(gdb) quit +talos2 ~ # coredumpctl gdb 509058 + PID: 509058 (make) + UID: 1000 (niko) + GID: 1000 (niko) + Signal: 11 (SEGV) + Timestamp: Wed 2023-02-15 17:11:24 CET (6min ago) + Command Line: /usr/bin/qemu-x86_64 /usr/bin/make VERSION=11.3.2 DESTDIR=/home/niko/devel/yay/pkg/yay PREFIX=/usr build + Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 + Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Unit: user@1000.service + User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Slice: user-1000.slice + Owner UID: 1000 (niko) + Boot ID: 33cad872d21043ebbe3dd6581bdd28c6 + Machine ID: b3e834569b8ff461391f5ac061feb773 + Hostname: talos2 + Storage: /var/lib/systemd/coredump/core.make.1000.33cad872d21043ebbe3dd6581bdd28c6.509058.1676477484000000.zst (present) + Size on Disk: 1.0M + Message: Process 509058 (make) of user 1000 dumped core. + +GNU gdb (Gentoo 12.1 vanilla) 12.1 +Copyright (C) 2022 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "powerpc64le-unknown-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://bugs.gentoo.org/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64... +BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002 +BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002 +BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 +BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 + +warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libguile-3.0.so.1.6.0 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libgc.so.1.5.1 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libffi.so.8.1.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libunistring.so.5.0.0 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libgmp.so.10.4.1 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libcrypt.so.2.0.0 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing + +warning: core file may not match specified executable file. +[New LWP 509058] +[New LWP 509060] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/usr/lib64/libthread_db.so.1". +Core was generated by `/usr/bin/qemu-x86_64 /usr/bin/make VERSION=11.3.2 DESTDIR=/home/niko/devel/yay/'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x0000000010278798 in sigsuspend () +[Current thread is 1 (Thread 0x1bde9000 (LWP 509058))] +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x1bde9000 (LWP 509058) 0x0000000010278798 in sigsuspend () + 2 Thread 0x3fffae0ef380 (LWP 509060) 0x00000000102cf6ec in syscall () +(gdb) quit +``` + +Download coredumps: + +https://drive.google.com/file/d/1GosaobKvmuRg-olaA1-aZcp7zAZcWmcF/view?usp=share_link + +https://drive.google.com/file/d/1N0BmlBIYY-qT5lHqlrKXvPL_FdYl3GfI/view?usp=share_link diff --git a/results/classifier/gemma3:12b/debug/1500 b/results/classifier/gemma3:12b/debug/1500 new file mode 100644 index 000000000..742a2237a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1500 @@ -0,0 +1,39 @@ + +Some system/debug regisiters are inconsistent with real device in qemu-system-arm +Description of problem: +We used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in system regisiter was detected. + +1. CCSIDR--Cache Size ID Registers + + **Inconsistency** + + - CCSIDR in QEMU: 0x701fe00a--Associativity: 2, Number of sets:256 + + - CCSIDR in Raspi2B: 0x700fe01a--Associativity: 4, Number of sets:128 + + **Tested Instruction sample** + + - MRC_T1A1_A 11101110001100000000111100010000 0xee300f10 + + According to ARMv7 Manual B4.1.19 encoding, the NumSets and Associativity are set different bewteen QEMU when emulating raspi2b and raspi2b. + + The CCSIDR is set in the function`cortex_a7_initfn(Object *obj)` in target/arm/cpu_tcg.c for cortex_a7. + +2. DBGDRAR--Debug ROM Address Register + + **Inconsistency** + + - DBGDRAR in QEMU: 0x0 --Invalid + + - DBGDRAR in Raspi2B: 0x40020003--Valid + + According to ARMv7 Manual C11.11.16 encoding, the DBGDRAR in qemu is invalid. + + **Tested Instruction sample** + + - MRC_T1A1_A 11101110000100010001111000010000 0xee111e10 +Steps to reproduce: +1. Compile a kernel module to run the test instruction in PL1. +2. Use kgdb to get the register info +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/1511710 b/results/classifier/gemma3:12b/debug/1511710 new file mode 100644 index 000000000..6bc19f4d9 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1511710 @@ -0,0 +1,8 @@ + +unknown option --disable-modules + +MSYS64, Windows 7 x64 + +$ ./configure --target-list=i386-softmmu --static --prefix=/d/qemu/ --disable-system --disable-user --disable-linux-user --disable-bsd-user --disable-guest-base --disable-docs --disable-guest-agent --disable-guest-agent-msi --disable-pie --disable-modules --disable-debug-tcg --disable-debug-info --disable-sparse --disable-seccomp --disable-gnutls --disable-sdl--disable-gtk --disable-vte --disable-curses --disable-vnc --disable-vnc-tls --disable-vnc-sasl --disable-vnc-jpeg --disable-vnc-png --disable-cocoa --disable-virtfs --disable-xen --disable-xen-pci-passthro --disable-brlapi --disable-curl --disable-fdt --disable-bluez --disable-kvm --disable-rdma --disable-uuid --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard-nss --disable-libusb --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-coroutine-pool --disable-glusterfs --disable-archipelago --disable-tpm --disable-libssh2 --disable-vhdx --disable-numa --disable-tcmalloc +ERROR: unknown option --disable-modules +Try './configure --help' for more information \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1513 b/results/classifier/gemma3:12b/debug/1513 new file mode 100644 index 000000000..6625a84ae --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1513 @@ -0,0 +1,2 @@ + +CPU flags should be better documented diff --git a/results/classifier/gemma3:12b/debug/1519037 b/results/classifier/gemma3:12b/debug/1519037 new file mode 100644 index 000000000..49c2c86b1 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1519037 @@ -0,0 +1,8 @@ + +qemu-i386 32-bit segfault + +I'm getting segfaults on 32-bit linux trying to run binaries using qemu-i386 from git. These segfaults go away when run in gdb or strace - could it be about the environment somehow? + +In contrast qemu-x86_64 works fine. How can I pinpoint the cause of this? + +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1523 b/results/classifier/gemma3:12b/debug/1523 new file mode 100644 index 000000000..baf49ff7a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1523 @@ -0,0 +1,2 @@ + +Tricore: no interrupts emulation diff --git a/results/classifier/gemma3:12b/debug/1527300 b/results/classifier/gemma3:12b/debug/1527300 new file mode 100644 index 000000000..4f7c34a40 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1527300 @@ -0,0 +1,10 @@ + +linux-user/elfload.c: byteswap function is not working when ELF is big endian + +I run qemu-mipsel for ELF with mips MSB(big endian), it always outputs error message: Invalid ELF image for this architecture. For the ELF I run: + +$file busybox + +ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped + +The section header is not corrupted(MSB, corrputed section header table also outputs same error as above), when I run ELF with LSB, it works perfectly. I debugged with /linux-user/elfload.c, I am sure that the problem comes from byteswap function. But I don't know how to handle it. I really hope this can be fixed ASAP. Really appreciate your help. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1528239 b/results/classifier/gemma3:12b/debug/1528239 new file mode 100644 index 000000000..5ddd76d86 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1528239 @@ -0,0 +1,46 @@ + +Unable to debug PIE binaries with QEMU gdb stub. + +The issue occurs on current trunk: + +max@max:~/build/qemu$ cat test.c +#include <stdio.h> + +int main() { + printf("Hello, world!\n"); + return 0; +} + +max@max:~/build/qemu$ gcc test.c -fPIC -pie -o bad.x +max@max:~/build/qemu$ ./x86_64-linux-user/qemu-x86_64 -g 1234 bad.x +............................. + + +max@max:~/build/qemu$ gdb +GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 +........................................................................................ +(gdb) file bad.x +Reading symbols from bad.x...(no debugging symbols found)...done. +(gdb) b main +Breakpoint 1 at 0x779 +(gdb) target remote localhost:1234 +Remote debugging using localhost:1234 +Reading symbols from /lib64/ld-linux-x86-64.so.2...warning: the debug information found in "/lib64/ld-2.19.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). + +Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done. +done. +Loaded symbols for /lib64/ld-linux-x86-64.so.2 +Error in re-setting breakpoint 1: Cannot access memory at address 0x775 +Error in re-setting breakpoint 1: Cannot access memory at address 0x775 +0x0000004000a042d0 in _start () from /lib64/ld-linux-x86-64.so.2 +(gdb) c +Continuing. +[Inferior 1 (Remote target) exited normally] +(gdb) + + +max@max:~/build/qemu$ cat config.log +# Configured with: '/home/max/src/qemu/configure' '--prefix=/home/max/install/qemu' '--target-list=arm-linux-user,aarch64-linux-user,x86_64-linux-user' '--static' + + +W/O QEMU or -pie flag breakpoint on main works fine. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1528718 b/results/classifier/gemma3:12b/debug/1528718 new file mode 100644 index 000000000..d94d96804 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1528718 @@ -0,0 +1,16 @@ + +Initial monitor does not output anything on Windows (MSYS2 binary) + +When running on Windows error messages before the UI is started are not showing up. + +For example when I run: + +qemu-system-i386.exe -L /mingw32/etc/qemu/ -m 20G + +It should display "ram size too large", according to gdb: + +Breakpoint 1, error_report (fmt=fmt@entry=0x71bdf6 <dma_aiocb_info+2426> "ram size too large") at C:/build/mingw/mingw-w64-qemu/src/qemu-2.4.0/util/qemu-error.c:233 + +However the console does never receive that. + +As far as I could find out vfprintf is called, but it doesn't output anything. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1548166 b/results/classifier/gemma3:12b/debug/1548166 new file mode 100644 index 000000000..af96caec9 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1548166 @@ -0,0 +1,30 @@ + +QEMU crash after send data from Host through serial port + +Hi All + +I have two computer, one is Win7 32 another is Win7 64, Both computer meet this issue. +My QEMU version is qemu-w32-setup-20160215 + +I want used EDK2 OVMF with Intel UDK Debugger tools to do source level debug +I had install com0com Virtual Com Port, and set COM3 connect to COM4 + +Intel UDK Debugger tools used COM3 +QEMU run OVMF used COM4 + +First execute Intel UDK Debugger tools, then launch QEMU +C:\Program Files\qemu\qemu-system-x86_64.exe -bios "C:\EDK2\Build\OvmfX64\DEBUG_VS2010\FV\OVMF.fd" -serial COM4 +Then QEMU crashes on stratup + +I have do some experiment +Execute terminal tool Tera Term and used COM3 +launch QEMU and used COM4 +C:\Program Files\qemu\qemu-system-x86_64.exe -bios "C:\EDK2\Build\OvmfX64\DEBUG_VS2010\FV\OVMF.fd" -serial COM4 +This is fine and i can see OVMF trace log on terminal +But if i press "Down" key on terminal, then QEMU crashe +It's caused by terminal send data("Down" key) to QEMU + +Have somebody can share some information about this? + +Thanks a lot. +Sugar \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1549654 b/results/classifier/gemma3:12b/debug/1549654 new file mode 100644 index 000000000..90acbb14a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1549654 @@ -0,0 +1,110 @@ + +qemu-system-arm emulator + +Hi, + +I don't know if this is a bug or a feature in new QEMU software. I was following an online tutorial using QEMU to develop a simple bare-metal program for qemu-system-arm. I decided to try a more recent software and I got surprised when I found the small code can not run on newer QEMU software (all newer than 2.0.0) but can run on the old QEMU from Ubuntu (Debian 2.0.0+dfsg-2ubuntu1.22) and the stock version from website. After putting the qemu-system-arm in single step and saving the log, the following is the output which you can see the 1st instruction stores R3 at [fp, #-8] and the second instruction can not restores the value from the same address to R0: + +0x00010074: e50b3008 str r3, [fp, #-8] + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=00010074 +PSR=400001d3 -Z-- A S svc32 +---------------- +IN: kmain +0x00010078: e51b0008 ldr r0, [fp, #-8] + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=00010078 +PSR=400001d3 -Z-- A S svc32 +---------------- +IN: kmain +0x0001007c: ebffffe3 bl 0x10010 + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=0001007c +PSR=400001d3 -Z-- A S svc32 + +-------------------------------------- +Meanwhile the older version of QEMU 2.0.0 does this very well and can execute the program normally: + +0x00010074: e50b3008 str r3, [fp, #-8] + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=00010074 +PSR=400001d3 -Z-- A svc32 +---------------- +IN: kmain +0x00010078: e51b0008 ldr r0, [fp, #-8] + +R00=00000000 R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=00010078 +PSR=400001d3 -Z-- A svc32 +---------------- +IN: kmain +0x0001007c: ebffffe3 bl 0x10010 + +R00=0001008c R01=00000000 R02=00000000 R03=0001008c +R04=00000000 R05=00000000 R06=00000000 R07=00000000 +R08=00000000 R09=00000000 R10=00000000 R11=00011094 +R12=00000000 R13=00011088 R14=00010008 R15=0001007c +PSR=400001d3 -Z-- A svc32 +---------------- + +The command line to use was: + +qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -smp 1 -m 64M -nographic -kernel kernel.elf -singlestep -D file.log -d in_asm,cpu + +The kernel.elf is a simple program (elf) file, created from two sources: + +boot.S: + +.global _RESET +_RESET: +LDR sp, =_STACK +BL kmain +B . + +And kernel.c: + +# define UART0_MEM 0x10009000 + +volatile unsigned int * const UART0 = (unsigned int *) UART0_MEM; +void dprint(const char* message){ + while(*message != 0) { + *UART0=*message; + ++message; + } +} +void kmain() { + const char *hi="Hello!"; + dprint(hi); +}; + +The linker scripts is: +ENTRY(_RESET) +SECTIONS +{ + . = 0x10000; + .boot . : { boot.o(.text) } + .text : { *(.text) } + .data : { *(.data) } + .bss : { *(.bss COMMON) } + . = ALIGN(8); + . = . + 0x1000; /* 4kB of stack memory */ + _STACK = .; +} + +This error cases the dprint function to find *message as 0 and do not print the output in newer QEMU software. + +Thank you for consideration. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1552 b/results/classifier/gemma3:12b/debug/1552 new file mode 100644 index 000000000..9ece41d8f --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1552 @@ -0,0 +1,16 @@ + +newer version(>=5.2.0) of qemu-system-aarch64 cannot debug arm64 linux kernel +Description of problem: + +Steps to reproduce: +1. Run QEMU in on teminal. +2. Run gdb-multiarch in another terminal, for example: gdb-multiarch ./linux-5.10.4/vmlinux +3. In gdb-multiarch, enter three commands in sequence："target remote localhost:1234"、"b do_sys_open"、"continue" +4. GDB breakpoint cannot take effect +5. If using qemu-system-aarch64 5.0.0(manually compiled)，GDB breakpoint can take effect. +Additional information: +I tested this problem using different combinations： +Host Os：Ubuntu18/Ubuntu20/Ubuntu22 +ARM64 Linux Kernel: 5.4.50/5.10.4 +QEMU：qemu 2.11/qemu 4.2/qemu 5.0/qemu 5.2/qemu 6.2/qemu 7 +Finally, I found out that arm64 linux kernel cannot be debugged since qemu-system-aarch64 5.2.0. diff --git a/results/classifier/gemma3:12b/debug/1555 b/results/classifier/gemma3:12b/debug/1555 new file mode 100644 index 000000000..03ccdca46 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1555 @@ -0,0 +1,33 @@ + +virt platform mrom +Description of problem: +qemu-system-riscv32 to emulated the lowrisc ibex simple system hello, when debug with riscv32-unknown-elf-gdb, there kept logging "Invalid read at addr 0x0, size 2, region '(null)', reason: rejected". +I saw qemu virt platform codes related to this error, it load reset_vec to 0x1000 called VIRT_MROM. I still not understand why this error happens. +Steps to reproduce: +1.git clone https://github.com/lowRISC/ibex.git +2.cd ibex +3.make -C examples/sw/simple_system/hello_test +4.using the qemu command line above +5.`riscv32-unknown-elf-gdb -ex target remote localhost:1234 examples/sw/simple_system/hello_test` in another terminal, type bt, the error happens. +Additional information: +```gdb +(gdb) x/16i $pc +=> 0x1000: auipc t0,0x0 + 0x1004: addi a2,t0,40 + 0x1008: csrr a0,mhartid + 0x100c: lw a1,32(t0) + 0x1010: lw t0,24(t0) + 0x1014: jr t0 + 0x1018: unimp + 0x101a: .2byte 0x8000 + 0x101c: unimp + 0x101e: unimp + 0x1020: unimp + 0x1022: .2byte 0x7fe0 + 0x1024: unimp + 0x1026: unimp + 0x1028: .4byte 0x4942534f + 0x102c: c.slli64 zero +(gdb) bt +#0 0x00001000 in ?? () +``` diff --git a/results/classifier/gemma3:12b/debug/1555452 b/results/classifier/gemma3:12b/debug/1555452 new file mode 100644 index 000000000..f51604085 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1555452 @@ -0,0 +1,10 @@ + +GDB server does not work in Windows + +I build qemu with msys2, MINGW64. After fix the socket_error() problem, and manually specify to use IPv4, GDB server still does not work. The related qemu command is +"-monitor none -nographic -gdb tcp::1234 -S" +GDB reports "Timed out" + +There's a message at https://<email address hidden>/msg357981.html. +I've fixed the socket_error() problem. +I see that qio_channel_create_socket_watch is called. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1563612 b/results/classifier/gemma3:12b/debug/1563612 new file mode 100644 index 000000000..9f1e4bcee --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1563612 @@ -0,0 +1,51 @@ + +pulseaudio applications crash under linux-user-x86_64 + +Running a simple application that uses pulseaudio under qemu-i386 or qemu-x86_64 makes it crash (tested on Debian 8.0): + +# apt-get install build-essential qemu-user libpulse-dev pulseaudio +$ cat > test.c << __EOF +#include <pulse/simple.h> + +int main(void) { + pa_simple *s; + pa_sample_spec ss; + ss.format = PA_SAMPLE_S16NE; + ss.channels = 2; + ss.rate = 44100; + s = pa_simple_new(NULL, // Use the default server. + "Fooapp", // Our application's name. + PA_STREAM_PLAYBACK, + NULL, // Use the default device. + "Music", // Description of our stream. + &ss, // Our sample format. + NULL, // Use default channel map + NULL, // Use default buffering + // attributes. + NULL // Ignore error code. + ); + + int16_t buf[2 * 1000]; + int i; + memset(buf, 0, sizeof buf); + for (i = 0; i < 44; i++) { + pa_simple_write(s, buf, sizeof buf, NULL); + } + + pa_simple_free(s); + + return 0; +} +__EOF +$ gcc test.c -o test -lpulse -lpulse-simple +$ ./test +<no output, no error> +$ qemu-x86_64 ./test +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +$ + + +I think this is related to the futex system call. In an attempt to debug the problem, I compiled pulseaudio in debug mode and it hit an assertion failure in pa_mutex_unlock. + +Thank you for developing QEMU. :-) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1590 b/results/classifier/gemma3:12b/debug/1590 new file mode 100644 index 000000000..d1b0f9eaf --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1590 @@ -0,0 +1,122 @@ + +Regression: ARMv8M secure mode debugging non-functional since ~v7.2.0 +Description of problem: +Prior to qemu commit 4a35855682cebb89f9630b07aa9fd37c4e8c733b, both semihosting printf calls and debugging via gdb work as expected. + +Builds of qemu containing commit 4a35855682cebb89f9630b07aa9fd37c4e8c733b do not produce any semihosting output and are not debuggable via gdb. +Steps to reproduce: +1. Run ``qemu-system-arm -machine mps2-an505 -nographic -semihosting -kernel build/mps2_an505_cm33_blink_demo.elf`` with qemu v7.1.0, note the "blinking" print to the console once a second. +2. Run ``qemu-system-arm -machine mps2-an505 -nographic -semihosting -kernel build/mps2_an505_cm33_blink_demo.elf`` with qemu v7.2.0, note that no messages are printed to the console. +3. Run ``qemu-system-arm -machine mps2-an505 -nographic -semihosting -kernel build/mps2_an505_cm33_blink_demo.elf -S -s`` and attach gdb with the following gdbinit file. +Additional information: +Log of successful gdb session with the attached patch on top of qemu master branch: +``` +% arm-none-eabi-gdb build/mps2_an505_cm33_blink_demo.elf +GNU gdb (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 13.1.90.20230307-git +Copyright (C) 2023 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "--host=x86_64-apple-darwin19.6.0 --target=arm-none-eabi". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://bugs.linaro.org/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from build/mps2_an505_cm33_blink_demo.elf... +The target architecture is set to "armv8-m.main". +Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:172 +172 { +Section .privileged_functions, range 0x10000000 -- 0x10008000: matched. +Section .text, range 0x10008000 -- 0x10019c18: matched. +Section .rodata, range 0x10019c18 -- 0x1001b270: matched. +Section .ARM.exidx, range 0x1001b270 -- 0x1001b278: matched. +Section .copy.table, range 0x1001b278 -- 0x1001b284: matched. +Section .data, range 0x1001b28c -- 0x1001bb90: matched. +Section .ram_vectors, range 0x1001bb90 -- 0x1001bdd0: matched. +Section .zero.table, range 0x1001b284 -- 0x1001b28c: matched. +Breakpoint 1 at 0x10009900: file /FreeRTOS/Demo/ARM_MPS/fault_handlers.c, line 494. +(gdb) s +174 asm volatile +(gdb) s +189 init_data_sections(); +(gdb) s +init_data_sections () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:99 +99 for( pCopyTable = &__copy_table_start__; pCopyTable <= &__copy_table_end__; pCopyTable++ ) +(gdb) s +101 for( dataIndex = 0; dataIndex < pCopyTable->uxLen; dataIndex++ ) +(gdb) info locals +pCopyTable = 0x1001b278 +dataIndex = 0 +(gdb) print /x *0xE000ED08 +$1 = 0x10000000 +``` + +Log of an unsuccessful gdb session with qemu v7.2.0 +``` +pbartell@147dda7342a9 ARM_MPS % arm-none-eabi-gdb build/mps2_an505_cm33_blink_demo.elf +GNU gdb (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 13.1.90.20230307-git +Copyright (C) 2023 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "--host=x86_64-apple-darwin19.6.0 --target=arm-none-eabi". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://bugs.linaro.org/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from build/mps2_an505_cm33_blink_demo.elf... +The target architecture is set to "armv8-m.main". +Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:172 +172 { +Section .privileged_functions, range 0x10000000 -- 0x10008000: MIS-MATCHED! +Section .text, range 0x10008000 -- 0x10019c18: MIS-MATCHED! +Section .rodata, range 0x10019c18 -- 0x1001b270: MIS-MATCHED! +Section .ARM.exidx, range 0x1001b270 -- 0x1001b278: MIS-MATCHED! +Section .copy.table, range 0x1001b278 -- 0x1001b284: MIS-MATCHED! +Section .data, range 0x1001b28c -- 0x1001bb90: MIS-MATCHED! +Section .ram_vectors, range 0x1001bb90 -- 0x1001bdd0: MIS-MATCHED! +Section .zero.table, range 0x1001b284 -- 0x1001b28c: MIS-MATCHED! +warning: One or more sections of the target image does not match +the loaded file + +Breakpoint 1 at 0x10009900: file /FreeRTOS/FreeRTOS/Demo/ARM_MPS/fault_handlers.c, line 494. +(gdb) s +Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:174 +174 asm volatile +(gdb) s +Reset_Handler () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:189 +189 init_data_sections(); +(gdb) s +init_data_sections () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:95 +95 { +(gdb) s +init_data_sections () at /FreeRTOS/FreeRTOS/Demo/ARM_MPS/startup.c:99 +99 for( pCopyTable = &__copy_table_start__; pCopyTable <= &__copy_table_end__; pCopyTable++ ) +(gdb) info locals +pCopyTable = <error reading variable pCopyTable (Cannot access memory at address 0x381fffdc)> +dataIndex = <error reading variable dataIndex (Cannot access memory at address 0x381fffd8)> +(gdb) print /x *0xE000ED08 +$1 = 0x0 +(gdb) quit +``` + +.gdbinit file: +``` +set architecture armv8-m.main +target extended-remote :1234 +compare-sections +break HardFault_Handler +``` + +[mps2_an505_cm33_blink_demo.elf](/uploads/c86e086b00651a8d5392857b9e4a2c4d/mps2_an505_cm33_blink_demo.elf) +[target-arm-Fix-debugging-of-ARMv8M-Secure-code.patch](/uploads/5735d5f7d7b15dbbeb0c2d214a46c1a8/target-arm-Fix-debugging-of-ARMv8M-Secure-code.patch) diff --git a/results/classifier/gemma3:12b/debug/1594394 b/results/classifier/gemma3:12b/debug/1594394 new file mode 100644 index 000000000..be9cc440f --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1594394 @@ -0,0 +1,42 @@ + +Using setreuid / setegid crashes x86_64 user-mode target + +When setreuid() or setegid() are called from x86_64 target code in user mode, qemu crashes inside the NPTL signal handlers. x86 targets do not directly use a syscall to handle setreuid() / setegid(); instead the x86 NPTL implementation sets up a temporary data region in memory (__xidcmd) and issues a signal (SIGRT1) to all threads, allowing the handler for that signal to issue the syscall. Under qemu, __xidcmd remains null (see variable display below backtrace). + +Backtrace: +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x3fff85c74fc0 (LWP 74517)] +0x000000006017491c in sighandler_setxid (sig=33, si=0x3fff85c72d08, ctx=0x3fff85c71f90) at nptl-init.c:263 +263 nptl-init.c: No such file or directory. +(gdb) thread apply all bt + +Thread 3 (Thread 0x3fff87e8efc0 (LWP 74515)): +#0 0x00000000601cc430 in syscall () +#1 0x0000000060109080 in futex_wait (val=<optimized out>, ev=<optimized out>) at /build/qemu/util/qemu-thread-posix.c:292 +#2 qemu_event_wait (ev=0x62367bb0 <rcu_call_ready_event>) at /build/qemu/util/qemu-thread-posix.c:399 +#3 0x000000006010f73c in call_rcu_thread (opaque=<optimized out>) at /build/qemu/util/rcu.c:250 +#4 0x0000000060176f8c in start_thread (arg=0x3fff87e8efc0) at pthread_create.c:336 +#5 0x00000000601cebf4 in clone () + +Thread 2 (Thread 0x3fff85c74fc0 (LWP 74517)): +#0 0x000000006017491c in sighandler_setxid (sig=33, si=0x3fff85c72d08, ctx=0x3fff85c71f90) at nptl-init.c:263 +#1 <signal handler called> +#2 0x00000000601cc42c in syscall () +#3 0x0000000060044b08 in safe_futex (val3=<optimized out>, uaddr2=0x0, timeout=<optimized out>, val=<optimized out>, op=128, uaddr=<optimized out>) at /build/qemu/linux-user/syscall.c:748 +#4 do_futex (val3=<optimized out>, uaddr2=275186650880, timeout=0, val=1129, op=128, uaddr=275186651116) at /build/qemu/linux-user/syscall.c:6201 +#5 do_syscall (cpu_env=0x1000abfd350, num=<optimized out>, arg1=275186651116, arg2=<optimized out>, arg3=1129, arg4=0, arg5=275186650880, arg6=<optimized out>, arg7=0, arg8=0) + at /build/qemu/linux-user/syscall.c:10651 +#6 0x00000000600347b8 in cpu_loop (env=0x1000abfd350) at /build/qemu/linux-user/main.c:317 +#7 0x0000000060036ae0 in clone_func (arg=0x3fffc4c2ca38) at /build/qemu/linux-user/syscall.c:5445 +#8 0x0000000060176f8c in start_thread (arg=0x3fff85c74fc0) at pthread_create.c:336 +#9 0x00000000601cebf4 in clone () + +Thread 1 (Thread 0x1000aa05000 (LWP 74511)): +#0 0x00000000601cc430 in syscall () +#1 0x0000000060044b08 in safe_futex (val3=<optimized out>, uaddr2=0x0, timeout=<optimized out>, val=<optimized out>, op=128, uaddr=<optimized out>) at /build/qemu/linux-user/syscall.c:748 +#2 do_futex (val3=<optimized out>, uaddr2=1, timeout=0, val=1, op=128, uaddr=275078324992) at /build/qemu/linux-user/syscall.c:6201 +#3 do_syscall (cpu_env=0x1000aa23890, num=<optimized out>, arg1=275078324992, arg2=<optimized out>, arg3=1, arg4=0, arg5=1, arg6=<optimized out>, arg7=0, arg8=0) at /build/qemu/linux-user/syscall.c:10651 +#4 0x00000000600347b8 in cpu_loop (env=0x1000aa23890) at /build/qemu/linux-user/main.c:317 +#5 0x00000000600020e4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /build/qemu/linux-user/main.c:4779 +(gdb) p __xidcmd +$1 = (struct xid_command *) 0x0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1596160 b/results/classifier/gemma3:12b/debug/1596160 new file mode 100644 index 000000000..a33a3e861 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1596160 @@ -0,0 +1,36 @@ + +SIGSEGV in memory_region_access_valid on Sabre Lite board + +I'm trying to emulate a Sabre Lite board and booting U-Boot, but I'm encountering a SIGSEGV almost immediately after starting QEMU. + +QEMU version: 6f1d2d1c5ad20d464705b17318cb7ca495f8078a +U-Boot version: mx6qsabrelite_defconfig 2016.05 (with http://git.denx.de/?p=u-boot.git;a=commitdiff;h=1f516faa45611aedc8c2e3f303b3866f615d481e reverted, since it hangs the CPU) + +$ gdb --args ./arm-softmmu/qemu-system-arm -machine sabrelite -kernel ~/u-boot-2016.05/u-boot +GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 + +... + +(gdb) r +Starting program: /home/kota/qemu/build/arm-softmmu/qemu-system-arm -machine sabrelite -kernel /home/kota/u-boot-2016.05/u-boot +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +[New Thread 0x7fffe9074700 (LWP 18025)] +[New Thread 0x7fffe58c0700 (LWP 18027)] + +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7fffe58c0700 (LWP 18027)] +0x00005555557aaaa8 in memory_region_access_valid (mr=mr@entry=0x7fffe594e0e0, addr=addr@entry=0, size=size@entry=4, is_write=is_write@entry=true) at /home/kota/qemu/memory.c:1143 +1143 if (!mr->ops->valid.unaligned && (addr & (size - 1))) { +(gdb) bt +#0 0x00005555557aaaa8 in memory_region_access_valid (mr=mr@entry=0x7fffe594e0e0, addr=addr@entry=0, size=size@entry=4, is_write=is_write@entry=true) at /home/kota/qemu/memory.c:1143 +#1 0x00005555557aacbd in memory_region_dispatch_write (mr=0x7fffe594e0e0, addr=0, data=3925868734, size=4, attrs=...) at /home/kota/qemu/memory.c:1249 +#2 0x00007fffe645a4e4 in code_gen_buffer () +#3 0x0000555555778d4d in cpu_tb_exec (itb=<optimized out>, itb=<optimized out>, cpu=0x7fffe58c92e0) at /home/kota/qemu/cpu-exec.c:166 +#4 cpu_loop_exec_tb (sc=0x7fffe58bfab0, tb_exit=<synthetic pointer>, last_tb=0x7fffe58bfaa0, tb=<optimized out>, cpu=0x7fffe58c92e0) at /home/kota/qemu/cpu-exec.c:530 +#5 cpu_arm_exec (cpu=cpu@entry=0x7fffe58c1080) at /home/kota/qemu/cpu-exec.c:626 +#6 0x0000555555798a20 in tcg_cpu_exec (cpu=0x7fffe58c1080) at /home/kota/qemu/cpus.c:1541 +#7 tcg_exec_all () at /home/kota/qemu/cpus.c:1574 +#8 qemu_tcg_cpu_thread_fn (arg=<optimized out>) at /home/kota/qemu/cpus.c:1171 +#9 0x00007ffff27f1184 in start_thread (arg=0x7fffe58c0700) at pthread_create.c:312 +#10 0x00007ffff251e37d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/160 b/results/classifier/gemma3:12b/debug/160 new file mode 100644 index 000000000..f48841a61 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/160 @@ -0,0 +1,2 @@ + +Record/replay example does not work diff --git a/results/classifier/gemma3:12b/debug/1602247 b/results/classifier/gemma3:12b/debug/1602247 new file mode 100644 index 000000000..d29b308b1 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1602247 @@ -0,0 +1,61 @@ + +SIGSEGV when reading ARM GIC registers through GDB stub + +When trying to access ARM GIC CPU registers through a target GDB connected to QEMU, QEMU crashes with a SIGSEGV. + +Reproducible on last master revision (74e1b78 at the time of writing): + +$ ./configure --target-list=arm-softmmu --python=python2 --enable-debug +$ make +$ gdb --args ./arm-softmmu/qemu-system-arm -M vexpress-a15 -smp 2 -s -S + + +Connect a gdb on the other side: +$ arm-none-eabi-gdb +(gdb) tar rem :1234 +Remote debugging using :1234 +0x00000000 in ?? () +(gdb) x /x 0x2c002000 + + +QEMU crashes as it tries to access current_cpu->cpu_index while current_cpu is NULL: + +Thread 1 "qemu-system-arm" received signal SIGSEGV, Segmentation fault. +0x0000555555a372cf in gic_get_current_cpu (s=0x555556a34f10) at hw/intc/arm_gic.c:53 +53 return current_cpu->cpu_index; +(gdb) p current_cpu +$1 = (CPUState *) 0x0 + +Backtrace: +(gdb) bt +#0 0x0000555555a372cf in gic_get_current_cpu (s=0x555556a34f10) at hw/intc/arm_gic.c:53 +#1 0x0000555555a3b0e3 in gic_thiscpu_read (opaque=0x555556a34f10, addr=0, data=0x7fffffffa0a8, size=4, attrs=...) at hw/intc/arm_gic.c:1340 +#2 0x00005555557ae2bb in memory_region_read_with_attrs_accessor (mr=0x555556a37a70, addr=0, value=0x7fffffffa208, size=4, shift=0, mask=4294967295, attrs=...) at /home/sekoia/devel/src/qemu/memory.c:461 +#3 0x00005555557ae7ac in access_with_adjusted_size (addr=0, value=0x7fffffffa208, size=4, access_size_min=1, access_size_max=4, access=0x5555557ae25f <memory_region_read_with_attrs_accessor>, mr=0x555556a37a70, attrs=...) + at /home/sekoia/devel/src/qemu/memory.c:591 +#4 0x00005555557b0de7 in memory_region_dispatch_read1 (mr=0x555556a37a70, addr=0, pval=0x7fffffffa208, size=4, attrs=...) at /home/sekoia/devel/src/qemu/memory.c:1187 +#5 0x00005555557b0e9d in memory_region_dispatch_read (mr=0x555556a37a70, addr=0, pval=0x7fffffffa208, size=4, attrs=...) at /home/sekoia/devel/src/qemu/memory.c:1212 +#6 0x000055555576775b in address_space_read_continue (as=0x5555569c70b0, addr=738205696, attrs=..., buf=0x7fffffffb440 "", len=4, addr1=0, l=4, mr=0x555556a37a70) at /home/sekoia/devel/src/qemu/exec.c:2668 +#7 0x0000555555767929 in address_space_read_full (as=0x5555569c70b0, addr=738205696, attrs=..., buf=0x7fffffffb440 "", len=4) at /home/sekoia/devel/src/qemu/exec.c:2725 +#8 0x00005555557679eb in address_space_read (len=4, buf=0x7fffffffb440 "", attrs=..., addr=738205696, as=0x5555569c70b0) at /home/sekoia/devel/src/qemu/include/exec/memory.h:1476 +#9 address_space_rw (as=0x5555569c70b0, addr=738205696, attrs=..., buf=0x7fffffffb440 "", len=4, is_write=false) at /home/sekoia/devel/src/qemu/exec.c:2739 +#10 0x000055555576988f in cpu_memory_rw_debug (cpu=0x5555568a3d00, addr=738205696, buf=0x7fffffffb440 "", len=4, is_write=0) at /home/sekoia/devel/src/qemu/exec.c:3653 +#11 0x00005555557a3db3 in target_memory_rw_debug (cpu=0x5555568a3d00, addr=738205696, buf=0x7fffffffb440 "", len=4, is_write=false) at /home/sekoia/devel/src/qemu/gdbstub.c:54 +#12 0x00005555557a53f5 in gdb_handle_packet (s=0x55555722c530, line_buf=0x55555722c54c "m2c002000,4") at /home/sekoia/devel/src/qemu/gdbstub.c:968 +#13 0x00005555557a6b84 in gdb_read_byte (s=0x55555722c530, ch=52) at /home/sekoia/devel/src/qemu/gdbstub.c:1458 +#14 0x00005555557a6ca4 in gdb_chr_receive (opaque=0x0, buf=0x7fffffffc590 "$m2c002000,4#84c8ead:arm-neon.xml:7fd,802#4c;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df", size=15) + at /home/sekoia/devel/src/qemu/gdbstub.c:1666 +#15 0x000055555591c562 in qemu_chr_be_write_impl (s=0x555557226e20, buf=0x7fffffffc590 "$m2c002000,4#84c8ead:arm-neon.xml:7fd,802#4c;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df", + len=15) at qemu-char.c:387 +#16 0x000055555591c5c0 in qemu_chr_be_write (s=0x555557226e20, buf=0x7fffffffc590 "$m2c002000,4#84c8ead:arm-neon.xml:7fd,802#4c;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df", len=15) + at qemu-char.c:399 +#17 0x00005555559207f3 in tcp_chr_read (chan=0x555556e52ff0, cond=G_IO_IN, opaque=0x555557226e20) at qemu-char.c:2893 +#18 0x0000555555c4a9b7 in qio_channel_fd_source_dispatch (source=0x555557226ca0, callback=0x55555592069d <tcp_chr_read>, user_data=0x555557226e20) at io/channel-watch.c:84 +#19 0x00007fffed977c8a in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +#20 0x0000555555bbf711 in glib_pollfds_poll () at main-loop.c:213 +#21 0x0000555555bbf7ec in os_host_main_loop_wait (timeout=29744918) at main-loop.c:258 +#22 0x0000555555bbf899 in main_loop_wait (nonblocking=0) at main-loop.c:506 +#23 0x0000555555929cd2 in main_loop () at vl.c:1908 +#24 0x00005555559315b7 in main (argc=8, argv=0x7fffffffdae8, envp=0x7fffffffdb30) at vl.c:4604 + +Note that this bug is triggered only when the number of simulated CPUs is greater than 1. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1603580 b/results/classifier/gemma3:12b/debug/1603580 new file mode 100644 index 000000000..da7669346 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1603580 @@ -0,0 +1,35 @@ + +[gdbstub] qemu is killed when using remote debugger with qemu -S -s + +Hello, + +REPRODUCE + +$ qemu-system-x86_64 -s -S -nographic +<wait> +QEMU: Terminated via GDBStub + +$ gdb +(gdb) target remote :1234 +(gdb) load /bin/ls +(gdb) target exec +A program is being debugged already. Kill it? (y or no) y +No executable file now. + +EXPECTED + +Enable program to be executed without terminating QEMU. + +DISCUSSION + +This was already discussed in [1], reverted in [2], however, no solution is provided. + +It worked perfectly in the past, I guess because of [1] and before [3]. + +Opening bug for this as discussion in mailing list did not attract anyone and functionality is required. If there is other gdb sequence to achieve same result it would be great to get it documented. + +Thanks, + +[1] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=00e94dbc7fd0110b0555d59592b004333adfb4b8 +[2] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ce0274f730eacbd24c706523ddbbabb6b95d0659 +[3] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7d03f82f81e0e6c106ca0d2445a0fc49dc9ddc7b \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1609 b/results/classifier/gemma3:12b/debug/1609 new file mode 100644 index 000000000..695a9022e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1609 @@ -0,0 +1,20 @@ + +SPARC emulation: userspace program run from gdb crashes OS running in emulator +Description of problem: +SPARC emulation: userspace program run from gdb crashes OS running in emulator +Steps to reproduce: +As a user (not root!): +1. as -Q n -K PIC -b -L mandelbrot.s +2. ld -m a.out -o test +3. gdb ./test +4. run + +`as' is from gnu binutils (binutils-2.20.1-sol26-sparc-local.gz). +Additional information: +[mandelbrot.s](/uploads/edfe6f1fd01fa39ecce9ba4201454ae3/mandelbrot.s) + +screenshot: https://imgur.com/a/JD51DJA + +It could very well be a bug in my assembly code, but it is still strange that it crashes the whole system. + +~"kind::Bug"[in_asm.dat.xz](/uploads/6bb43ce2b7d6973da4751d236fb44e12/in_asm.dat.xz) diff --git a/results/classifier/gemma3:12b/debug/1614348 b/results/classifier/gemma3:12b/debug/1614348 new file mode 100644 index 000000000..611d620b3 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1614348 @@ -0,0 +1,40 @@ + +qemu-arm core dumped for no entry symbol programe + +Hi qemu developers, + +Environment: +* Fedora 24 x86_64 +* qemu-arm version 2.6.92, Copyright (c) 2003-2008 Fabrice Bellard +* arm-linux-gnu-gcc 6.1.1 20160621 (Red Hat Cross 6.1.1-2) (GCC) target: arm-linux-gnueabi +* glibc-arm-linux-gnu-devel-2.23 + +very simple hello.c: + +#include <stdio.h> + +int main(int argc, char *argv[]) +{ + printf("Hello World\n"); + + return 0; +} + +arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib -lc + +/usr/bin/arm-linux-gnu-ld: Warning: Cannot find entry symbol _start; defaulting to 00000000000101fc + +qemu-arm -L /usr/arm-linux-gnu ./a.out + +Hello World +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction + +But provided entry symbol: + +arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib /usr/arm-linux-gnu/lib/crt1.o /usr/arm-linux-gnu/lib/crti.o /usr/arm-linux-gnu/lib/crtn.o -lc + +qemu-arm -L /usr/arm-linux-gnu ./a.out is able to work happily! + +Regards, +Leslie Zhai \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1624 b/results/classifier/gemma3:12b/debug/1624 new file mode 100644 index 000000000..e935665f6 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1624 @@ -0,0 +1,24 @@ + +8.0.0: Crash when emulating MIPS executable +Description of problem: +A change to QEMU introduced within the 6.0.0 development cycle causes MIPS executable to crash. +Similar problem occurred within the same time-frame for Aarch64 executables, but was fixed. +Patches in QEMU causing both Aarch64 and MIPS occurrences are identified and attached below. +Steps to reproduce: +1. Download attached core_test.zip archive. +2. Run pre-built MIPS executable with QEMU. +3. Observe the crash somewhere in tdelete. +4. Source for the test is here: https://github.com/VectorChief/QuadRay-engine +5. The binaries were built with GCC 9.4 cross-compilers using slightly modified makefiles (-ggdb3) for gdb-multiarch +6. Building on Ubuntu 22.04 and Ubuntu 23.04 also reproduces the problem, so it's not OS or compiler specific. +Additional information: +Archive with pre-built binaries: [core_test.zip](/uploads/529833c6f83aeec253df647a94868f8a/core_test.zip) + +Patch breaking Aarch64: [qemu_arm_br.diff](/uploads/476321e40a551e964be41a8bfda96613/qemu_arm_br.diff) +commit 8fe35e0444be88de4e3ab80a2a0e210a1f6d663d + +Patch fixing Aarch64: [qemu_arm_fix.diff](/uploads/2db3892d6839e9a4dfaf427359d6f004/qemu_arm_fix.diff) +commit ae30e86661b0f48562cd95918d37cbeec5d02262 + +Patch breaking MIPS: [qemu_mips_br.diff](/uploads/0a482e61c1245e5783364db845a55dfa/qemu_mips_br.diff) +commit 96e5b4c7584d623f6cdcb0083829c19141b2b130 diff --git a/results/classifier/gemma3:12b/debug/1625216 b/results/classifier/gemma3:12b/debug/1625216 new file mode 100644 index 000000000..5bf49f9b2 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1625216 @@ -0,0 +1,72 @@ + +memory writes via gdb don't work for memory mapped hardware + +When I remote-debug a qemu-guest and attempt to write to a memory mapped location, the +write-handler for the concerned device will not be called. All write-requiests from +gdb are delegated to cpu_physical_memory_write_rom(...). a function that writes to the +underlying ram-block. + +I believe requests to memory mapped hardware should be delegated to +address_space_rw(). + +example: +;; a memory mapped device. No effect, the write-handler is not called +(gdb) set *0xfff3c000 = 48 + +;; a ram or rom-block. Thos works. The value is changed. +(gdb) set *0x100000 = 48 + + +---------------------------------------- + +Here's my suggested patch. As noted in the comment, it could perhaps be +improved for the (rare) case when the write-request from gdb spans multiple +memory regions. + +$ git diff 85bc2a15121e8bcd9f15eb75794a1eacca9d84bd HEAD ../exec.c +diff --git a/exec.c b/exec.c +index c4f9036..45ef896 100644 +--- a/exec.c ++++ b/exec.c +@@ -3676,6 +3676,7 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr, + int l; + hwaddr phys_addr; + target_ulong page; ++ bool is_memcpy_access; + + while (len > 0) { + int asidx; +@@ -3691,13 +3692,32 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr, + if (l > len) + l = len; + phys_addr += (addr & ~TARGET_PAGE_MASK); ++ + if (is_write) { ++ /* if ram/rom region we access the memory ++ via memcpy instead of via the cpu */ ++ hwaddr mr_len, addr1; ++ AddressSpace *as = cpu->cpu_ases[asidx].as; ++ MemoryRegion *mr = address_space_translate(as, phys_addr, &addr1, &mr_len, is_write); ++ is_memcpy_access = memory_region_is_ram(mr) || memory_region_is_romd(mr); ++ if(mr_len < len) { ++ /* TODO, mimic more of the loop over mr chunks as ++ done in cpu_physical_memory_write_internal */ ++ printf("warning: we dont know whether all bytes " ++ "to be written are ram/rom or io\n"); ++ } ++ } ++ else { ++ is_memcpy_access = false; ++ } ++ ++ if (is_write && is_memcpy_access) { + cpu_physical_memory_write_rom(cpu->cpu_ases[asidx].as, + phys_addr, buf, l); + } else { + address_space_rw(cpu->cpu_ases[asidx].as, phys_addr, + MEMTXATTRS_UNSPECIFIED, +- buf, l, 0); ++ buf, l, is_write); + } + len -= l; + buf += l; \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/163 b/results/classifier/gemma3:12b/debug/163 new file mode 100644 index 000000000..115c77c89 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/163 @@ -0,0 +1,2 @@ + +SPICE session's connection_id's are not unique diff --git a/results/classifier/gemma3:12b/debug/1636126 b/results/classifier/gemma3:12b/debug/1636126 new file mode 100644 index 000000000..88e08f5af --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1636126 @@ -0,0 +1,20 @@ + +qemu-system-arm segfaults on "smulbb r7, r5, r5" + +I'll attach a binary that runs fine with qemu-system-arm V2.2.0 but V2.7.0 segfaults. +By stepping through with gdb I found that the segfaults happens when executing the line "smulbb r7, r5, r5" (where r7=0x1, r5=0x12). +I'll also attach a debugger screenshot. + +call and output: + +/opt/qemu-system-arm -M integratorcp -cpu cortex-m3 -semihosting -nographic -monitor null -serial null -no-reboot -kernel 0MFW_SafetyFunctions_ParameteruP1_CUNIT.elf + +------------ CUnit_MFW_SafetyFunctions_Parameter ------------ + + + CUnit - A Unit testing framework for C - Version 2.1-0 + http://cunit.sourceforge.net/ + + +Suite: Suite_MFW_SafetyFunctions_Parameter + Test: MFW_SafetyFunctions_Parameter_PositionLimiter ... Segmentation fault (core dumped) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1645355 b/results/classifier/gemma3:12b/debug/1645355 new file mode 100644 index 000000000..2ec6a43ab --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1645355 @@ -0,0 +1,30 @@ + +x86: singlestepping through SYSCALL instruction causes exception in kernelspace + +Hi, + +The bug was originally reported [1] and [2] here. There is a problem inside QEMU with singlestepping from userspace until SYSCALL instruction is reached. The OS has in FMASK TF bit set, therefore there should be no singlestepping exception when transitioning to kernelmode. But, inside QEMU there is (TF is clear seems FMASK is applied). See below for further details. + +The reproducer is available at [2]. + +Here is the original text with some minor clarifications: + +It seems that there is something wrong with QEMU with respect to handle the singlestepping and AMD64 syscall instruction. + +The AMD "syscall" instruction will clear defined flag in the FMASK MSR. Normally the TF flag is set there, so the first instruction when kernel is entered after syscall won't cause single step exception in the kernel. + +The observed scenario is a unhandled singlestep fault in the kernel or host reboot or QEMU crash. + +The possible way how to reproduce it is to single step through any function (in userspace) which does "syscall" instruction. After syscall is entered QEMU will trigger singlestepping exception in the kernel despite that the TF is set in FMASK MSR. Real HW behaves correctly and does not trigger this exception. + + +What is interesting is that I was not able to trigger it if I just enabled TF and did the syscall instruction, perhaps for this bug is somewhat important to have TF set for previous few instruction. + + +I have stumbled to this problem while working with our custom OS. However after some googling I found out that the NetBSD guys (CCed) are having very similar problem and I asked them to prepare a ISO image where the problem ends with QEMU SIGSEGV or host reboot. + +Thanks +Rudolf + +[1] https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg02289.html +[2] http://gnats.netbsd.org/49603 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1647683 b/results/classifier/gemma3:12b/debug/1647683 new file mode 100644 index 000000000..818951409 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1647683 @@ -0,0 +1,35 @@ + +Bad interaction between tb flushing & gdb stub + +I have been working on a series of patches for ARM big-endian system mode support, using QEMU as a bare-metal simulator for the GDB test suite. At some point I realised that these tests were not running reliably on the QEMU master branch, even without my patches applied. (I.e., in little-endian mode.) + +Running QEMU under GDB in the test harness via Valgrind, using something akin to: + +(gdb) target remote | valgrind --tool=memcheck qemu-arm-system [...] + +leads to intermittent (and quite hard-to-reproduce) segfaults in QEMU of the form: + +==52333== Process terminating with default action of signal 11 (SIGSEGV) +==52333== Access not within mapped region at address 0x24 +==52333== at 0x1D55F2: tb_page_remove (translate-all.c:1026) +==52333== by 0x1D58B4: tb_phys_invalidate (translate-all.c:1119) +==52333== by 0x1D63AA: tb_invalidate_phys_page_range (translate-all.c:1519) +==52333== by 0x1D66D7: tb_invalidate_phys_addr (translate-all.c:1714) +==52333== by 0x1CBA7F: breakpoint_invalidate (exec.c:704) +==52333== by 0x1CC01F: cpu_breakpoint_remove_by_ref (exec.c:869) +==52333== by 0x1CBF97: cpu_breakpoint_remove (exec.c:857) +==52333== by 0x218FAA: gdb_breakpoint_remove (gdbstub.c:717) +==52333== by 0x219E35: gdb_handle_packet (gdbstub.c:1035) +==52333== by 0x21AF62: gdb_read_byte (gdbstub.c:1459) +==52333== by 0x21B096: gdb_chr_receive (gdbstub.c:1672) +==52333== by 0x3AF2BC: qemu_chr_be_write_impl (qemu-char.c:419) + +These crashes didn't happen on a 2.6-era QEMU, so I bisected and discovered the commit 3359baad36889b83df40b637ed993a4b816c4906 ("tcg: Make tb_flush() thread safe") appears to be the thing that triggers this intermittent failure. Reverting the patch on the branch tip makes the crashes go away. + +Unfortunately I don't currently have a way to trigger the segfaults outside of Mentor Graphics's test infrastructure, which I can't share. + +Does anyone know a reason that this might be happening, or suggestions of how I might further debug this? Maybe a missed tb flush in the gdb stub code, somewhere? + +Thanks! + +Julian \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1649 b/results/classifier/gemma3:12b/debug/1649 new file mode 100644 index 000000000..916d6fb9e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1649 @@ -0,0 +1,18 @@ + +"slli" instruction before "la" and "csrw" sequence leads to failure in setting the cs register +Description of problem: +slli a0, a0, 8 (1) + la a0, mtimvec (2) + csrw mtvec, a0 (3) + mtimvec: (4) + +For the above assembly snippet, the mtvec could be successfully set to the value of a0 +without the presence of the line (1) or with the shift amount being zero. However, +the mtvec can never be set successfully with the presence of line (1). +Steps to reproduce: +1. Create a test.s file and put these 4 lines of assembly into the file +2. In terminal, run: "riscv64-unknown-elf-gcc -Ttext 0x80000000 -c test.s -o test", "riscv64-unknown-elf-objcopy test -S -O binary test", and "qemu-system-riscv64 test -s -S" +3. In another terminal window, run [riscv64-unknown-elf-gdb -ex "target remote localhost:1234" -ex "layout asm"]. Keep running si command in gdb until you are at 0x80000000 where you shall see the first instruction as shown in line (1). Then keep going till you have stepped over the instruction shown in line (3). Now, run "p $mtvec" in gdb, you shall see its value being 0. +4. Redo the above steps without line (1), you shall see mtvec loaded successfully with the correct value. +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/1654137 b/results/classifier/gemma3:12b/debug/1654137 new file mode 100644 index 000000000..41bd04869 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1654137 @@ -0,0 +1,8 @@ + +Ctrl-A b not working in 2.8.0 + +With a recent update from 2.7.0 to 2.8.0 I have discovered that I can no longer send a "break" to the VM. Ctrl-A b is simply ignored. Other Ctrl-A sequences seem to work correctly. + +This is on a NetBSD amd64 system, version 7.99.53, and qemu was installed on this system from source. + +Reverting to the previous install restores "break" capability. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1662 b/results/classifier/gemma3:12b/debug/1662 new file mode 100644 index 000000000..6ff26cf77 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1662 @@ -0,0 +1,36 @@ + +qemu-system-loongarch64 start Loongnix system coredump +Description of problem: + +Steps to reproduce: +1. build qemu: + ./configure --prefix=/usr --disable-werror --disable-gtk --target-list="loongarch64-softmmu"\ + --enable-debug + make -j32 +2. get bios and qcow2: + wget https://mirrors.wsyu.edu.cn/loongarch/archlinux/images/QEMU_EFI_7.2.fd + wget http://pkg.loongnix.cn/loongnix/isos/Loongnix-20.4/Loongnix-20.4.cartoon.gui.loongarch64.en.qcow2 +3. start Loongnix + ./build/qemu-system-loongarch64 \ + -m 8G \ + -cpu la464 \ + -machine virt \ + -smp 16 \ + -bios ./QEMU_EFI_7.2.fd \ + -serial stdio \ + -device virtio-gpu-pci \ + -net nic -net user \ + -device nec-usb-xhci,id=xhci,addr=0x1b \ + -device usb-tablet,id=tablet,bus=xhci.0,port=1 \ + -device usb-kbd,id=keyboard,bus=xhci.0,port=2 \ + -device virtio-blk-pci,drive=test -drive if=none,id=test,file=./Loongnix-20.4.cartoon.gui.loongarch64.en.qcow2 + +4. VNC connect +5. use the system + login loongson/Loongson20 +6. qemu coredump + + qemu-system-loongarch64: /root/work/qemu/include/tcg/tcg.h:675: temp_idx: Assertion `n >= 0 && n < tcg_ctx->nb_temps' failed. +./start-loongnix.sh: line 13: 40242 Aborted (core dumped) ./build/qemu-system-loongarch64 -m 8G -cpu la464 -machine virt -smp 16 -bios ./QEMU_EFI_7.2.fd -serial stdio -device virtio-gpu-pci -net nic -net user -device nec-usb-xhci,id=xhci,addr=0x1b -device usb-tablet,id=tablet,bus=xhci.0,port=1 -device usb-kbd,id=keyboard,bus=xhci.0,port=2 -device virtio-blk-pci,drive=test -drive if=none,id=test,file=./Loongnix-20.4.cartoon.gui.loongarch64.en.qcow2 +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/1671 b/results/classifier/gemma3:12b/debug/1671 new file mode 100644 index 000000000..427c4a55f --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1671 @@ -0,0 +1,1358 @@ + +segfault/errors in gdbstub with linux userspace emulator (qemu-riscv64), from racy behavior with singal handler? +Description of problem: +Often, qemu segfaults, sometimes GDB just spits out a wall of "Ignoring packet error, continuing..." and ~hangs: I don't get a GDB command prompt quickly, if at all, and when I ctrl-c I see "The target is not responding to GDB commands. Stop debugging it? (y or n)". +Steps to reproduce: +1. Run the `testb3` binary from below as described +2. Connect via GDB and `continue` +3. Multiple threads (independently) SIGABRT themselves when they fail their test(s), which happens quickly on my machine (which has 16 physical cores) +Additional information: +From the coredump, it looks like there's a lot of cooks in the gdbstub kitchen: + +``` + Id Target Id Frame +* 1 Thread 0x7febc02ef6c0 (LWP 3922802) gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282 + 2 Thread 0x7febc06db6c0 (LWP 3922792) safe_syscall_base () + at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 + 3 Thread 0x7febc03b26c0 (LWP 3922799) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 + 4 Thread 0x7febc0f5d6c0 (LWP 3922751) 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6 + 5 Thread 0x7febc0f5ebc0 (LWP 3922750) safe_syscall_base () + at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 + 6 Thread 0x7febc01696c0 (LWP 3922808) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 7 Thread 0x7febc04f76c0 (LWP 3922794) 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6 + 8 Thread 0x7febc026d6c0 (LWP 3922804) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 9 Thread 0x7febc01aa6c0 (LWP 3922807) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 10 Thread 0x7febc075c6c0 (LWP 3922793) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 11 Thread 0x7febc04756c0 (LWP 3922796) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 + 12 Thread 0x7febc01eb6c0 (LWP 3922806) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 13 Thread 0x7febc022c6c0 (LWP 3922805) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 + 14 Thread 0x7febc03f36c0 (LWP 3922798) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 15 Thread 0x7febc04346c0 (LWP 3922797) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 16 Thread 0x7febc03716c0 (LWP 3922800) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 + 17 Thread 0x7febc04b66c0 (LWP 3922795) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 18 Thread 0x7febc02ae6c0 (LWP 3922803) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 19 Thread 0x7febc03306c0 (LWP 3922801) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +``` + +Each of those `read` and `send` threads look something similar to this one: + +``` +Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +``` + +Which, at a guess, seems like there's maybe 20 different concurrent processes fighting over the singular [gdbstub state](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/gdbstub.c#L57)? Specifically, they're all stomping on each other by writing to the same [buffer](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/user.c#L136) and advancing the [current CPU list pointer](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/gdbstub.c#L1422), which causes the "bad packet" cross-talk and the segfault respectively. + +<details><summary>full backtrace</summary> + +``` +(gdb) thread apply all bt full + +Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)): +#0 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82 +No locals. +#2 0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161 +No locals. +#3 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#4 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#5 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#6 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#7 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#8 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#9 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +No locals. +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +No locals. +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +No locals. +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +No locals. +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +No locals. +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +No locals. +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +No locals. +#7 0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962 +No locals. + +Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)): +#0 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29 +No locals. +#2 qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464 +No locals. +#3 0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261 +No locals. +#4 0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541 +No locals. +#5 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#6 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +No locals. +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +No locals. +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +No locals. +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +No locals. +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +No locals. +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +No locals. +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +No locals. +#7 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#8 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#9 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)): +#0 gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282 +No locals. +#1 0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411 +No locals. +#2 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#3 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#4 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#5 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#6 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#7 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#8 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#9 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +(gdb) thread apply all bt + +Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)): +#0 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6 +#1 0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82 +#2 0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161 +#3 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#4 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#5 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#6 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#7 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#8 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#9 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +#7 0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962 + +Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)): +#0 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6 +#1 0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29 +#2 qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464 +#3 0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261 +#4 0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541 +#5 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#6 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +#7 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#8 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#9 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)): +#0 gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282 +#1 0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411 +#2 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#3 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#4 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#5 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#6 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#7 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#8 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#9 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +(gdb) thread apply all bt full + +Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)): +#0 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82 +No locals. +#2 0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161 +No locals. +#3 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#4 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#5 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#6 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#7 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#8 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#9 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +No locals. +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +No locals. +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +No locals. +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +No locals. +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +No locals. +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +No locals. +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +No locals. +#7 0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962 +No locals. + +Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)): +#0 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29 +No locals. +#2 qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464 +No locals. +#3 0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261 +No locals. +#4 0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541 +No locals. +#5 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#6 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +No locals. +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +No locals. +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +No locals. +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +No locals. +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +No locals. +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +No locals. +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +No locals. +#7 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#8 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#9 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)): +#0 gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282 +No locals. +#1 0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411 +No locals. +#2 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#3 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#4 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#5 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#6 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#7 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#8 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#9 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +``` + +</details> + + + +- coredump + - [core.qemu-riscv64.1000.efb558e6104b4cc5bfa37605fc9af294.3922750.1685497956000000.zst](/uploads/071fc96520ca4008941044802c176d6a/core.qemu-riscv64.1000.efb558e6104b4cc5bfa37605fc9af294.3922750.1685497956000000.zst) + - [qemu-riscv64](/uploads/f203d5aed8559d80c2d66e439bb4dddf/qemu-riscv64) (the binary the coredump was generated from) + - download both, extract corefile, use `DEBUGINFOD_URLS=https://debuginfod.archlinux.org gdb /path/to/qemu-riscv64 -c /tmp/coredump` to debug +- reproducer + - [testb3.tar.xz](/uploads/84bdbb547e01527c3d804e0d88c6c9fe/testb3.tar.xz) (includes testb3 + sysroot to work with command line above) + - This binary is a cross-compiled `testb3` from [WebKit](https://github.com/WebKit/WebKit/blob/9755847ab1d40841374b2467b3036d943b723183/Source/JavaScriptCore/b3/testb3_1.cpp#L927) ; sorry, that's about all I know about it so far + - A GDB you might use to connect is [SiFive's](https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.1.0-2019.01.0-x86_64-linux-ubuntu14.tar.gz). I got more consistent segfaults with a more recent gdb (12.1), but I'm not sure how to tell you how to get that `gdb` besides "creating a riscv64 poky distribution" (what I did), which is likely not helpful. diff --git a/results/classifier/gemma3:12b/debug/1671876 b/results/classifier/gemma3:12b/debug/1671876 new file mode 100644 index 000000000..00351a29e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1671876 @@ -0,0 +1,69 @@ + +qemu 2.7.0 segfaults in qemu_co_queue_run_restart() + +I've been experiencing frequent segfaults lately with qemu 2.7.0 running Ubuntu 16.04 guests. The crash usually happens in qemu_co_queue_run_restart(). I haven't seen this so far with any other guests or distros. + +Here is one back trace I obtained from one of the crashing VMs. + +------------------------------------------------------------------------------------------------- +(gdb) bt +#0 qemu_co_queue_run_restart (co=0x7fba8ff05aa0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:59 +#1 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8ff05aa0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#2 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba8dd20430) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#3 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8dd20430) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#4 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba8dd14ea0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#5 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8dd14ea0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#6 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba80c11dc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#7 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba80c11dc0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#8 0x000055c1656f3e74 in qemu_co_queue_run_restart (co=0x7fba8dd0bd70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#9 0x000055c1656f39a9 in qemu_coroutine_enter (co=0x7fba8dd0bd70) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#10 0x000055c1656f3fa0 in qemu_co_enter_next (queue=queue@entry=0x55c1669e75e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#11 0x000055c165692060 in timer_cb (blk=0x55c1669e7590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#12 0x000055c16564f615 in timerlist_run_timers (timer_list=0x55c166a53e80) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#13 0x000055c16564f679 in timerlistgroup_run_timers (tlg=tlg@entry=0x55c167c81cf8) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#14 0x000055c16564ff47 in aio_dispatch (ctx=ctx@entry=0x55c167c81bb0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#15 0x000055c1656500e8 in aio_poll (ctx=0x55c167c81bb0, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#16 0x000055c1654b1c79 in iothread_run (opaque=0x55c167c81960) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#17 0x00007fbc4b64f0a4 in allocate_stack (stack=<synthetic pointer>, pdp=<synthetic pointer>, attr=0x0) at allocatestack.c:416 +#18 __pthread_create_2_1 (newthread=<error reading variable: Cannot access memory at address 0xffffffffffffff48>, attr=<error reading variable: Cannot access memory at address 0xffffffffffffff40>, + start_routine=<error reading variable: Cannot access memory at address 0xffffffffffffff58>, arg=<error reading variable: Cannot access memory at address 0xffffffffffffff50>) at pthread_create.c:539 +Backtrace stopped: Cannot access memory at address 0x8 +------------------------------------------------------------------------------------------------- + +The code that crashes is this +------------------------------------------------------------------------------------------------- +void qemu_co_queue_run_restart(Coroutine *co) +{ + Coroutine *next; + + trace_qemu_co_queue_run_restart(co); + while ((next = QSIMPLEQ_FIRST(&co->co_queue_wakeup))) { + QSIMPLEQ_REMOVE_HEAD(&co->co_queue_wakeup, co_queue_next); <--- Crash occurs here this time + qemu_coroutine_enter(next); + } +} +------------------------------------------------------------------------------------------------- + +Expanding the macro QSIMPLEQ_REMOVE_HEAD gives us +------------------------------------------------------------------------------------------------- +#define QSIMPLEQ_REMOVE_HEAD(head, field) do { \ + if (((head)->sqh_first = (head)->sqh_first->field.sqe_next) == NULL)\ + (head)->sqh_last = &(head)->sqh_first; \ +} while (/*CONSTCOND*/0) +------------------------------------------------------------------------------------------------- + +which corrsponds to +------------------------------------------------------------------------------------------------- +if (((&co->co_queue_wakeup)->sqh_first = (&co->co_queue_wakeup)->sqh_first->co_queue_next.sqe_next) == NULL)\ + (&co->co_queue_wakeup)->sqh_last = &(&co->co_queue_wakeup)->sqh_first; +------------------------------------------------------------------------------------------------- + +Debugging the list we see +------------------------------------------------------------------------------------------------- +(gdb) print *(&co->co_queue_wakeup->sqh_first) +$6 = (struct Coroutine *) 0x1000 +(gdb) print *(&co->co_queue_wakeup->sqh_first->co_queue_next) +Cannot access memory at address 0x1030 +------------------------------------------------------------------------------------------------- + +So the data in co->co_queue_wakeup->sqh_first is corrupted and represents an invalid address. Any idea why is that? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1673130 b/results/classifier/gemma3:12b/debug/1673130 new file mode 100644 index 000000000..1fa0f26d4 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1673130 @@ -0,0 +1,74 @@ + +qemu 2.7.0 receives SIGABRT in qemu_coroutine_enter() + +I've been experiencing frequent SIGABRTs (in addition to segfaults in #1671876) lately with qemu 2.7.0 running Ubuntu 16.04 guests. The crash usually happens in qemu_coroutine_enter(). I haven't seen this so far with any other guests or distros. + +Here is one stack trace I obtained +-------------------------------------------------------------------------- +(gdb) bt +#0 0x00007fd7cc676067 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 +#1 0x00007fd7cc677448 in __GI_abort () at abort.c:89 +#2 0x0000556aed247b6c in qemu_coroutine_enter (co=0x7fd574300df0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:113 +#3 0x0000556aed247e55 in qemu_co_queue_run_restart (co=0x7fd574300ce0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#4 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd574300ce0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#5 0x0000556aed247e74 in qemu_co_queue_run_restart (co=0x7fd589111670) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#6 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd589111670) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#7 0x0000556aed247e74 in qemu_co_queue_run_restart (co=0x7fd57430dba0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#8 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd57430dba0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#9 0x0000556aed247e74 in qemu_co_queue_run_restart (co=0x7fd589119130) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#10 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd589119130) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#11 0x0000556aed247e74 in qemu_co_queue_run_restart (co=0x7fd589117410) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#12 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd589117410) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#13 0x0000556aed247e74 in qemu_co_queue_run_restart (co=0x7fd577f00e00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:60 +#14 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd577f00e00) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +#15 0x0000556aed247fa0 in qemu_co_enter_next (queue=queue@entry=0x556aef34e5e0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine-lock.c:106 +#16 0x0000556aed1e6060 in timer_cb (blk=0x556aef34e590, is_write=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/block/throttle-groups.c:400 +#17 0x0000556aed1a3615 in timerlist_run_timers (timer_list=0x556aef3bad40) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:528 +#18 0x0000556aed1a3679 in timerlistgroup_run_timers (tlg=tlg@entry=0x556af0738758) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/qemu-timer.c:564 +#19 0x0000556aed1a3f47 in aio_dispatch (ctx=ctx@entry=0x556af0738610) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:357 +#20 0x0000556aed1a40e8 in aio_poll (ctx=0x556af0738610, blocking=<optimized out>) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/aio-posix.c:479 +#21 0x0000556aed005c79 in iothread_run (opaque=0x556af07383c0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/iothread.c:46 +#22 0x00007fd7cc9f40a4 in start_thread (arg=0x7fd7aafff700) at pthread_create.c:403 +#23 0x00007fd7cc72962d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +-------------------------------------------------------------------------- + +The code crashes here +-------------------------------------------------------------------------- +void qemu_coroutine_enter(Coroutine *co) +{ + Coroutine *self = qemu_coroutine_self(); + CoroutineAction ret; + + trace_qemu_coroutine_enter(self, co, co->entry_arg); + + if (co->caller) { + fprintf(stderr, "Co-routine re-entered recursively\n"); + abort(); <--- Code aborts here + } + + [...] +} +-------------------------------------------------------------------------- + +Debugging further we see: +-------------------------------------------------------------------------- +(gdb) frame 2 +#2 0x0000556aed247b6c in qemu_coroutine_enter (co=0x7fd574300df0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:113 +113 /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c: No such file or directory. +(gdb) print *co +$1 = {entry = 0x7fd793e95a58, entry_arg = 0x1, caller = 0x7fd793e95a38, pool_next = {sle_next = 0x10}, co_queue_wakeup = {sqh_first = 0x7fd6ebbd2000, sqh_last = 0x1000}, co_queue_next = { + sqe_next = 0x7fd6ebbd1000}} +(gdb) print *co->caller +$2 = {entry = 0x400400000001, entry_arg = 0xc546a20, caller = 0x0, pool_next = {sle_next = 0x0}, co_queue_wakeup = {sqh_first = 0x0, sqh_last = 0xffffea00061f7480}, co_queue_next = {sqe_next = 0x100000000000}} +(gdb) frame 4 +#4 0x0000556aed2479a9 in qemu_coroutine_enter (co=0x7fd574300ce0) at /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c:119 +119 in /build/pb-qemu-pssKUp/pb-qemu-2.7.0/util/qemu-coroutine.c +(gdb) print *co +$3 = {entry = 0xc00000053, entry_arg = 0x7fd500000001, caller = 0x7fd574300d88, pool_next = {sle_next = 0x7fd574300d90}, co_queue_wakeup = {sqh_first = 0x7fd6ebbd1000, sqh_last = 0x7fd574300e00}, + co_queue_next = {sqe_next = 0xc546a20}} +(gdb) print *co->caller +$4 = {entry = 0x230095a58, entry_arg = 0x230095a38, caller = 0x187dd2000, pool_next = {sle_next = 0x187dd1000}, co_queue_wakeup = {sqh_first = 0x187dd0000, sqh_last = 0x187dcf000}, co_queue_next = { + sqe_next = 0x184970000}} +-------------------------------------------------------------------------- + +The question is, why did qemu_coroutine_enter not complain when in earlier calls co->caller was not NULL? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1674 b/results/classifier/gemma3:12b/debug/1674 new file mode 100644 index 000000000..dfe528005 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1674 @@ -0,0 +1,24 @@ + +Arrow key not functional in QEMU monitor when using nographic on Windows 11 host +Description of problem: +The arrow keys do not work on the Windows QEMU when using -nographic option. On the Linux QEMU they work. +Steps to reproduce: +1. Download the qemu source code from https://download.qemu.org/qemu-8.0.0.tar.xz. THe sha256sum of the file is bb60f0341531181d6cc3969dd19a013d0427a87f918193970d9adb91131e56d0. +2. Prepare the build system on MSYS2 according to the instructions on https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2. +3. Uncompress the source code using `tar -xf qemu-8.0.0.tar.xz`. +4. Change the working directory to qemu-8.0.0/. The build configuration command is `./configure --target-list=arm-softmmu --extra-cflags="-g -ggdb"` +5. Run the command `./qemu-system-arm -s -S -M virt -nographic`. +6. Press Ctrl-C A to switch to QEMU monitor. +7. Input "help" command to the monitor. +8. Press Arrow-Up key. +9. The previous "help" command does not appear in the monitor prompt. +Additional information: +1. The pre-built binary downloaded from https://qemu.weilnetz.de/w64/qemu-w64-setup-20230424.exe has the same behaviour. +2. The QEMU from MSYS2, `pacman -S mingw-w64-x86_64-qemu`, has the same behaviour. +3. If the "-nographic" option is removed, the arrow-up key works in the GTK console. +4. Neither of arrow-up, arrow-down, arrow-right, arrow-left key work. +5. If the valid kernel and rootfs are added in the command line by "-kernel" and "-initrd" options, neither key work after booting to the Linux successfully. +6. If the code `dwMode |= ENABLE_LINE_INPUT;` in the function `qemu_chr_open_stdio()` is changed to `dwMode |= ENABLE_LINE_INPUT|ENABLE_VIRTUAL_TERMINAL_INPUT;`, build again. All arrow keys work. +7. The VT sequence support was added in `EmulatorPkg/Win/Host/WinThunk.c` by this commit https://gitlab.com/qemu-project/edk2/-/commit/5601e90d5cdbc4cea748e00e34ae07ce39bd700f. +8. The above commit is to add VT sequence support at compile-time. Microsoft provides some code to enable it at run-time on https://learn.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#example-of-enabling-virtual-terminal-processing. +9. The function readline_handle_byte() is not called when the VT sequence is not enabled. diff --git a/results/classifier/gemma3:12b/debug/1686170 b/results/classifier/gemma3:12b/debug/1686170 new file mode 100644 index 000000000..317822b10 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1686170 @@ -0,0 +1,112 @@ + +qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options + +OS: Void Linux x86_64 (glibc) +QEMU version: 2.9.0 +GDB version: 7.12.1 + +Problem description: + +After I updated QEMU from version 2.8.1 to 2.9.0, I found that when I try to connect GDB to a running QEMU and try to debug Real mode machine code, I can no longer set architecture to 'i8086'. +To be able to connect to QEMU from GDB at all, I have to specify one of the 64 bit architectures, which among other things leads to incorrect disassembly listings. This makes debugging Real mode bootloaders, bootsectors and BIOS code much more difficult. + +Steps to reproduce: + +- Run QEMU +- In another terminal, run GDB +- In GDB, connect to QEMU +- In GDB, disassemble some Real mode machine code. + +Expected results (from QEMU version 2.8.1): + + [terminal #1] + $ qemu-system-x86_64 -S -s + + [terminal #2] + (gdb) set architecture i8086 + warning: A handler for the OS ABI "GNU/Linux" is not built + into this configuration + of GDB. Attempting to continue with the default i8086 settings. + + The target architecture is assumed to be i8086 + (gdb) target remote :1234 + Remote debugging using :1234 + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + 0x0000fff0 in ?? () + (gdb) x/i $cs*16+$eip + 0xffff0: ljmp $0xf000,$0xe05b + +Actual results: + + [terminal #1] + $ qemu-system-x86_64 -S -s + + [terminal #2] + $ gdb -q + (gdb) set architecture i8086 + warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration + of GDB. Attempting to continue with the default i8086 settings. + + The target architecture is assumed to be i8086 + (gdb) target remote :1234 + Remote debugging using :1234 + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + Remote 'g' packet reply is too long: + [..snip..] + +Workarounds tried: + + - Try different architecures + (gdb) set architecture i386:intel + The target architecture is assumed to be i386:intel + (gdb) target remote :1234 + Remote debugging using :1234 + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + Remote 'g' packet reply is too long: + [..snip..] + (gdb) set architecture i386:x86-64 + The target architecture is assumed to be i386:x86-64 + (gdb) target remote :1234 + Remote debugging using :1234 + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + 0x000000000000fff0 in ?? () + +The last try finally allowed me to connect to QEMU, but as can be expected from using an incorrect architecture setting, disassembly output is complete gibberish: + + (gdb) x/10i $cs*16+$rip + 0xffff0: (bad) + 0xffff1: pop %rbx + 0xffff2: loopne 0xffff4 + 0xffff4: lock xor %dh,(%rsi) + 0xffff7: (bad) + 0xffff8: xor (%rbx),%dh + 0xffffa: (bad) + 0xffffb: cmp %edi,(%rcx) + 0xffffd: add %bh,%ah + 0xfffff: add %al,(%rax) + +Discussion: + +I think I've traced the problem to the following commit: "x86: Fix x86_64 'g' packet response to gdb from 32-bit mode."[1]. +While I admire the effort to make life for people using GDB to debug QEMU VMs, I think the problem here is with GDB and can't be fixed entirely from the side of QEMU without breaking other features. + +In fact, there is a well-known workaround to this problem published on OSDev Wiki (Workaround #1)[2] which doesn't require patching either QEMU or GDB. This workaround has worked for me using several previous versions of QEMU. + + $ gdb -q + (gdb) set architecture i8086 + (gdb) target remote :1234 + (gdb) break some_breakpoint_in_32_bit_or_64_bit_code + (gdb) continue + [...] + Remote 'g' packet reply is too long: [...] + (gdb) disconnect # IMPORTANT STEP #1 + (gdb) set architecture i386:x86-64 + (gdb) target remote :1234 # IMPORTANT STEP #2 + (gdb) continue + +[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=e3592bc9d841c397eeda87f0019fab94ff71004b +[2]: http://wiki.osdev.org/QEMU_and_GDB_in_long_mode#Workaround_1:_Reconnecting \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1691379 b/results/classifier/gemma3:12b/debug/1691379 new file mode 100644 index 000000000..45589310f --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1691379 @@ -0,0 +1,46 @@ + +NetBSD evbmips64el port installation doesn't work with qemu-system-mips64el. + +I successfully installed the NetBSD evbmips64el port on gxemul but was unable to install it on qemu. Trying to boot it on qemu takes me to the 'db>' prompt. Here's the output and backtrace: + +panic: pcib_isa_intr_string: bogus isa irq 0x0 +kernel: breakpoint trap +Stopped in pid 0.1 (system) at netbsd:cpu_Debugger+0x4: jr ra + bdslot: nop +db> bt +0xffffffff805977f0: cpu_Debugger+4 (63061,90000000180003f8,6,ffffffff804c2290) ra ffffffff8030acd0 sz 0 +0xffffffff805977f0: vpanic+158 (63061,90000000180003f8,6,ffffffff804c2290) ra ffffffff8030ad7c sz 64 +0xffffffff80597830: panic+34 (63061,ffffffff803d65b0,0,40) ra ffffffff80109784 sz 96 +0xffffffff80597890: pcib_isa_intr_string+6c (63061,ffffffff803d65b0,0,40) ra ffffffff80149bfc sz 16 +0xffffffff805978a0: uhci_pci_attach+16c (63061,ffffffff803d65b0,0,40) ra ffffffff802f0400 sz 176 +0xffffffff80597950: config_attach_loc+1c8 (63061,ffffffff803d65b0,0,40) ra ffffffff802f053c sz 64 +0xffffffff80597990: config_found_sm_loc+5c (63061,ffffffff803d65b0,0,40) ra ffffffff80121354 sz 64 +0xffffffff805979d0: pci_probe_device+524 (63061,ffffffff803d65b0,0,0) ra ffffffff80121548 sz 288 +0xffffffff80597af0: pci_enumerate_bus+1d0 (63061,ffffffff803d65b0,0,0) ra ffffffff8012167c sz 160 +0xffffffff80597b90: pcirescan+5c (63061,ffffffff803d65b0,0,0) ra ffffffff801218c4 sz 32 +0xffffffff80597bb0: pciattach+19c (63061,ffffffff803d65b0,0,0) ra ffffffff802f0400 sz 80 +0xffffffff80597c00: config_attach_loc+1c8 (63061,ffffffff803d65b0,0,0) ra ffffffff802f053c sz 64 +0xffffffff80597c40: config_found_sm_loc+5c (63061,ffffffff803d65b0,0,0) ra ffffffff80108934 sz 64 +0xffffffff80597c80: gt_attach+7c (63061,ffffffff803d65b0,0,0) ra ffffffff802f0400 sz 112 +0xffffffff80597cf0: config_attach_loc+1c8 (63061,ffffffff803d65b0,0,0) ra ffffffff802f053c sz 64 +0xffffffff80597d30: config_found_sm_loc+5c (63061,ffffffff803d65b0,0,0) ra ffffffff801086ac sz 64 +0xffffffff80597d70: mainbus_attach+dc (63061,ffffffff803d65b0,0,0) ra ffffffff802f0400 sz 96 +0xffffffff80597dd0: config_attach_loc+1c8 (63061,ffffffff803d65b0,0,0) ra ffffffff80104bf8 sz 64 +0xffffffff80597e10: cpu_configure+28 (63061,ffffffff803d65b0,0,0) ra ffffffff803d5f30 sz 16 +0xffffffff80597e20: main+3a0 (63061,ffffffff803d65b0,0,0) ra ffffffff801000dc sz 128 +0xffffffff80597ea0: kernel_text+dc (63061,ffffffff803d65b0,0,0) ra 0 sz 0 +User-level: pid 0.1 + +Here's the command that I used: + +Build evbmips64el from source and then launch it from qemu (replace the paths relative to your system): + +qemu-system-mips64el -cdrom /extra/evbmips64/distrib/evbmips/cdroms/installcd/NetBSD-7.99.71-evbmips-mips64el.iso -hda /extra/evbmips64.img -kernel /extra/evbmips64/releasedir/evbmips/installation/netbsd-INSTALL_MALTA64 -nographic -M malta + +(I've decompressed the kernel) + +Here's the output for qemu-system-mips64el --version : + +QEMU emulator version 2.7.1(qemu-2.7.1-6.fc25), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + +This doesn't look like a NetBSD bug. I've attached a screenshot of the working installation using gxemul in the attachments. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1699824 b/results/classifier/gemma3:12b/debug/1699824 new file mode 100644 index 000000000..1bd895a86 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1699824 @@ -0,0 +1,230 @@ + +qemu-system-sparc64 -M sun4v aborts on tribblix-sparc-0m16.iso + +qemu-system-sparc64 qemu-2.9.0-3.10.x86_64 on openSUSE Leap 42.3 using 'sun4v' machine aborts with tribblix. With 2048 MB of RAM it takes considerably more time to abort (but the core is always truncated). + +> qemu-system-sparc64 -m 1024 -cdrom tribblix-sparc-0m16.iso -boot d -nographic -M sun4v +qemu: fatal: Trap 0x0010 while trap level (6) >= MAXTL (6), Error state +pc: 0000000000000200 npc: 0000000000000204 +%g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%o4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%l0-3: 000000003ff00000 000001ff00000000 000001fff0080000 0000000000000000 +%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +pstate: 00000014 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 6 pil: 0 gl: 8 +tbr: 0000000000000000 hpstate: 0000000000000004 htba: 0000000000000000 +cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 + +Aborted (core dumped) + + + PID: 26999 (qemu-system-spa) + UID: 1000 (newman) + GID: 100 (users) + Signal: 6 (ABRT) + Timestamp: Thu 2017-06-22 16:19:02 CEST (1min 5s ago) + Command Line: qemu-system-sparc64 -m 1024 -cdrom tribblix-sparc-0m16.iso -boot d -nographic -M sun4v + Executable: /usr/bin/qemu-system-sparc64 + Control Group: / + Slice: -.slice + Boot ID: aa7431274f854fb7a02a773eefa8a9bb + Machine ID: 89c660865c00403a9bacef32b6828556 + Hostname: assam.suse.cz + Coredump: /var/lib/systemd/coredump/core.qemu-system-spa.1000.aa7431274f854fb7a02a773eefa8a9bb.26999.1498141142000000.xz + Message: Process 26999 (qemu-system-spa) of user 1000 dumped core. + + + +(gdb) thread apply all bt full + +Thread 4 (Thread 0x7f3896aca700 (LWP 27001)): +#0 0x00007f38bb983295 in do_futex_wait () at /lib64/libpthread.so.0 +#1 0x00007f38bb983349 in __new_sem_wait_slow () at /lib64/libpthread.so.0 +#2 0x00007f38bb9833f7 in sem_timedwait () at /lib64/libpthread.so.0 +#3 0x00005599ec6a1147 in qemu_sem_timedwait (sem=sem@entry=0x5599ef168628, ms=ms@entry=10000) at util/qemu-thread-posix.c:255 + rc = <optimized out> + ts = {tv_sec = 1498141152, tv_nsec = 280531000} + __func__ = "qemu_sem_timedwait" +#4 0x00005599ec69c83c in worker_thread (opaque=0x5599ef1685c0) at util/thread-pool.c:92 + req = <optimized out> + ret = <optimized out> + pool = 0x5599ef1685c0 +#5 0x00007f38bb97c744 in start_thread () at /lib64/libpthread.so.0 +#6 0x00007f38b79bdd3d in clone () at /lib64/libc.so.6 + +Thread 3 (Thread 0x7f38bee01c40 (LWP 26999)): +#0 0x00007f38b79b555f in ppoll () at /lib64/libc.so.6 +#1 0x00005599ec69d289 in ppoll (__ss=0x0, __timeout=0x7ffd1dcf2a20, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:77 + ts = {tv_sec = 1, tv_nsec = 0} +Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.: +#2 0x00005599ec69d289 in qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=1000000000) at util/qemu-timer.c:334 + ts = {tv_sec = 1, tv_nsec = 0} +Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.: +#3 0x00005599ec69dff8 in os_host_main_loop_wait (timeout=1000000000) at util/main-loop.c:255 + context = 0x5599ef147470 + ret = <optimized out> + spin_counter = 0 + ret = -283872144 + timeout = 1000 +#4 0x00005599ec69dff8 in main_loop_wait (nonblocking=<optimized out>) at util/main-loop.c:517 + ret = -283872144 + timeout = 1000 +#5 0x00005599ec3c8c5f in main_loop () at vl.c:1900 + i = <optimized out> + snapshot = <optimized out> + linux_boot = <optimized out> + initrd_filename = <optimized out> + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = <optimized out> + boot_once = 0x0 + ds = <optimized out> + cyls = <optimized out> + heads = <optimized out> + secs = <optimized out> + translation = <optimized out> + opts = <optimized out> + hda_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = <optimized out> + olist = <optimized out> + optind = 10 + optarg = 0x7ffd1dcf51d2 "sun4v" + loadvm = <optimized out> + machine_class = 0x5599ec6d6f6f + cpu_model = <optimized out> + vga_model = 0x5599ec6d6f81 "std" + qtest_chrdev = <optimized out> + qtest_log = <optimized out> + pid_file = <optimized out> + incoming = <optimized out> + defconfig = <optimized out> + userconfig = <optimized out> + nographic = <optimized out> + display_type = <optimized out> + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = <optimized out> + vmstate_dump_file = <optimized out> + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffd1dcf2ba0} + rlimit_as = {rlim_cur = 18446744073709551615, rlim_max = 18446744073709551615} + __func__ = "main" + __FUNCTION__ = "main" +#6 0x00005599ec3c8c5f in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4730 + i = <optimized out> + snapshot = <optimized out> + linux_boot = <optimized out> + initrd_filename = <optimized out> + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = <optimized out> + boot_once = 0x0 + ds = <optimized out> + cyls = <optimized out> + heads = <optimized out> + secs = <optimized out> + translation = <optimized out> + opts = <optimized out> + hda_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = <optimized out> + olist = <optimized out> + optind = 10 + optarg = 0x7ffd1dcf51d2 "sun4v" + loadvm = <optimized out> + machine_class = 0x5599ec6d6f6f + cpu_model = <optimized out> + vga_model = 0x5599ec6d6f81 "std" + qtest_chrdev = <optimized out> + qtest_log = <optimized out> + pid_file = <optimized out> + incoming = <optimized out> + defconfig = <optimized out> + userconfig = <optimized out> + nographic = <optimized out> + display_type = <optimized out> + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = <optimized out> + vmstate_dump_file = <optimized out> + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffd1dcf2ba0} + rlimit_as = {rlim_cur = 18446744073709551615, rlim_max = 18446744073709551615} + __func__ = "main" + __FUNCTION__ = "main" + +Thread 2 (Thread 0x7f38abf99700 (LWP 27000)): +#0 0x00007f38b79b98e9 in syscall () at /lib64/libc.so.6 +#1 0x00005599ec6a12d6 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /usr/src/debug/qemu-2.9.0/include/qemu/futex.h:26 + value = <optimized out> +#2 0x00005599ec6a12d6 in qemu_event_wait (ev=ev@entry=0x5599ed0f1e40 <rcu_gp_event>) at util/qemu-thread-posix.c:399 + value = <optimized out> +#3 0x00005599ec6b0a78 in wait_for_readers () at util/rcu.c:131 + qsreaders = {lh_first = 0x7f38abf99588} + index = <optimized out> + tmp = <optimized out> +#4 0x00005599ec6b0a78 in synchronize_rcu () at util/rcu.c:162 +#5 0x00005599ec6b0c79 in call_rcu_thread (opaque=<optimized out>) at util/rcu.c:256 + tries = 0 + n = 565 + node = <optimized out> +#6 0x00007f38bb97c744 in start_thread () at /lib64/libpthread.so.0 +#7 0x00007f38b79bdd3d in clone () at /lib64/libc.so.6 + +Thread 1 (Thread 0x7f38962c9700 (LWP 27002)): +#0 0x00007f38b79088d7 in raise () at /lib64/libc.so.6 +#1 0x00007f38b7909caa in abort () at /lib64/libc.so.6 +#2 0x00005599ec3d1125 in cpu_abort (cpu=cpu@entry=0x5599ef16f800, fmt=fmt@entry=0x5599ec6d3388 "Trap 0x%04x while trap level (%d) >= MAXTL (%d), Error state") at /usr/src/debug/qemu-2.9.0/exec.c:962 + ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7f38962c88b0, reg_save_area = 0x7f38962c87d0}} + ap2 = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7f38962c88b0, reg_save_area = 0x7f38962c87d0}} +#3 0x00005599ec4790b8 in sparc_cpu_do_interrupt (cs=0x5599ef16f800) at /usr/src/debug/qemu-2.9.0/target/sparc/int64_helper.c:119 + cpu = 0x5599ef16f800 + __func__ = "sparc_cpu_do_interrupt" + env = 0x5599ef177a98 + intno = 16 + tsptr = 0x6 +#4 0x00005599ec3dcf54 in cpu_handle_exception (ret=<synthetic pointer>, cpu=0x5599ef12e000) at /usr/src/debug/qemu-2.9.0/cpu-exec.c:463 + cc = 0x5599ef12e000 + cc = <optimized out> + __func__ = "cpu_exec" + ret = <optimized out> + sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = <optimized out>} + __FUNCTION__ = "cpu_exec" +#5 0x00005599ec3dcf54 in cpu_exec (cpu=cpu@entry=0x5599ef16f800) at /usr/src/debug/qemu-2.9.0/cpu-exec.c:668 + cc = <optimized out> + __func__ = "cpu_exec" + ret = <optimized out> + sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = <optimized out>} + __FUNCTION__ = "cpu_exec" +#6 0x00005599ec40796d in tcg_cpu_exec (cpu=0x5599ef16f800) at /usr/src/debug/qemu-2.9.0/cpus.c:1260 + ret = <optimized out> + r = -1775462656 + cpu = 0x5599ef16f800 +#7 0x00005599ec40796d in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) at /usr/src/debug/qemu-2.9.0/cpus.c:1355 + r = -1775462656 + cpu = 0x5599ef16f800 +#8 0x00007f38bb97c744 in start_thread () at /lib64/libpthread.so.0 +#9 0x00007f38b79bdd3d in clone () at /lib64/libc.so.6 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1701971 b/results/classifier/gemma3:12b/debug/1701971 new file mode 100644 index 000000000..6677c7867 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1701971 @@ -0,0 +1,46 @@ + +multithreading not working right under qemu user mode for sh4 + +In a multithreaded program running under qemu-sh4 (version 2.9.0), thread termination and/or pthread_join is not working right. + +The attached program works natively on all kinds of platforms, and under qemu user mode emulation for at least alpha, armelhf, aarch64, powerpc64le. + +How to reproduce: +- Compile the program: sh4-linux-gnu-gcc-5 -O -Wall -lpthread -o test-tls test-tls.c +- Set environment variables for running qemu-sh4. +- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-tls + +Expected behaviour: After the "Worker xxxxx dying" line, the main() function prints "OK", and the program terminates. + +Actual behaviour (only on sh4): After the "Worker xxxxx dying" line, it hangs. Attaching gdb to qemu shows 15 threads with a stack trace like +#0 safe_syscall_base () at /build/qemu-2.9.0/linux-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x00005584f86f4c48 in safe_futex (uaddr=<optimized out>, op=op@entry=128, val=val@entry=2, timeout=<optimized out>, uaddr2=uaddr2@entry=0x0, + val3=val3@entry=-161181992) at /build/qemu-2.9.0/linux-user/syscall.c:921 +#2 0x00005584f870353b in do_futex (val3=-161181992, uaddr2=4134624624, timeout=0, val=<optimized out>, op=<optimized out>, uaddr=<optimized out>) + at /build/qemu-2.9.0/linux-user/syscall.c:7147 +#3 do_syscall (cpu_env=<optimized out>, num=240, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=0, arg5=-160342672, + arg6=-161181992, arg7=0, arg8=0) at /build/qemu-2.9.0/linux-user/syscall.c:11692 +#4 0x00005584f86f454a in cpu_loop (env=env@entry=0x5584fb3d04f8) at /build/qemu-2.9.0/linux-user/main.c:2676 +#5 0x00005584f86f5dd5 in clone_func (arg=0x7fff4d485c20) at /build/qemu-2.9.0/linux-user/syscall.c:6234 +#6 0x00007f08f05a46ba in start_thread (arg=0x7f08f1368700) at pthread_create.c:333 +#7 0x00007f08f02da3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 + +and 1 thread with a stack trace like +#0 safe_syscall_base () at /build/qemu-2.9.0/linux-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x00005584f86f4c48 in safe_futex (uaddr=<optimized out>, op=op@entry=0, val=val@entry=18875, timeout=<optimized out>, uaddr2=uaddr2@entry=0x0, + val3=val3@entry=-161180376) at /build/qemu-2.9.0/linux-user/syscall.c:921 +#2 0x00005584f870353b in do_futex (val3=-161180376, uaddr2=4135101768, timeout=0, val=<optimized out>, op=<optimized out>, uaddr=<optimized out>) + at /build/qemu-2.9.0/linux-user/syscall.c:7147 +#3 do_syscall (cpu_env=<optimized out>, num=240, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=0, arg5=-159865528, + arg6=-161180376, arg7=0, arg8=0) at /build/qemu-2.9.0/linux-user/syscall.c:11692 +#4 0x00005584f86f454a in cpu_loop (env=0x5584fb3b99a8) at /build/qemu-2.9.0/linux-user/main.c:2676 +#5 0x00005584f86c12d3 in main (argc=<optimized out>, argv=0x7fff4d4878b8, envp=<optimized out>) + at /build/qemu-2.9.0/linux-user/main.c:4860 + +and 1 thread with a stack trace like +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x00005584f876eab5 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /build/qemu-2.9.0/include/qemu/futex.h:26 +#2 qemu_event_wait (ev=ev@entry=0x5584faa43d84 <rcu_call_ready_event>) at /build/qemu-2.9.0/util/qemu-thread-posix.c:399 +#3 0x00005584f87748ce in call_rcu_thread (opaque=<optimized out>) at /build/qemu-2.9.0/util/rcu.c:249 +#4 0x00007f08f05a46ba in start_thread (arg=0x7f08eff62700) at pthread_create.c:333 +#5 0x00007f08f02da3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1703147 b/results/classifier/gemma3:12b/debug/1703147 new file mode 100644 index 000000000..156fdba1a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1703147 @@ -0,0 +1,9 @@ + +Xfer:features:read truncating xml sent to gdb frontends + +Around line 1326 in gdbstub.c: + + if (len > (MAX_PACKET_LENGTH - 5) / 2) + len = (MAX_PACKET_LENGTH - 5) / 2; + +is truncating processor reg description xml files longer than 2045 bytes. Deleting these lines works for my immediate need, but they seem to be trying to fix some buffer overrun condition so I won't offer a patch until we understand their purpose. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1704186 b/results/classifier/gemma3:12b/debug/1704186 new file mode 100644 index 000000000..7d508b972 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1704186 @@ -0,0 +1,10 @@ + +no option for handling ^C in stdio + +There is no way to tell qemu to handle (or not) ^C on standard input. + +This makes using serial console on stdio needlessly annoying and difficult. + +The code is there - depending on how you set up the console it may handle the signal or not. + +That's completely backwards. The behavior should be the same regardless of how you set up console *and* there should be a separate option for handling ^C. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1704638 b/results/classifier/gemma3:12b/debug/1704638 new file mode 100644 index 000000000..b83aaef98 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1704638 @@ -0,0 +1,66 @@ + +weak symbol access makes qemu in user mode hang for mips, mips64 + +A program that is statically linked and invokes a weak pointer should crash (because the weak pointer evaluates to NULL). + +With qemu in user mode, for mips and mips64, it hangs. The process needs to be killed with "kill -9". + +How to reproduce for mips: +- Compile the program: mips-linux-gnu-gcc-5 -O -Wall -static -o testpthsigmask-mips testpthsigmask.c -pthread +- Set environment variables for running qemu-mips. +- ~/inst-qemu/2.9.0/bin/qemu-mips testpthsigmask-mips + +How to reproduce for mips64: +- Compile the program: mips64-linux-gnuabi64-gcc-5 -O -Wall -static -o testpthsigmask-mips64 testpthsigmask.c -lpthread +- Set environment variables for running qemu-mips64. +- ~/inst-qemu/2.9.0/bin/qemu-mips64 testpthsigmask-mips64 + +When I attach gdb to the process, I see that it is hanging inside 'gen_intermediate_code': + +$ gdb /home/bruno/inst-qemu/2.9.0/bin/qemu-mips 9726 +... +Reading symbols from /home/bruno/inst-qemu/2.9.0/bin/qemu-mips...done. +Attaching to program: /home/bruno/inst-qemu/2.9.0/bin/qemu-mips, process 9726 +... +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x7f1e7e535740 (LWP 9726) "qemu-mips" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 + 2 Thread 0x7f1e7d0ad700 (LWP 9727) "qemu-mips" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +(gdb) where +#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 +#1 0x00007f1e7d6f1dbd in __GI___pthread_mutex_lock (mutex=mutex@entry=0x55de1c7ff830 <tcg_ctx+272>) at ../nptl/pthread_mutex_lock.c:80 +#2 0x000055de1c527199 in qemu_mutex_lock (mutex=mutex@entry=0x55de1c7ff830 <tcg_ctx+272>) + at /media/develdata/devel/build/qemu-2.9.0/util/qemu-thread-posix.c:60 +#3 0x000055de1c435083 in tb_lock () at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:167 +#4 cpu_restore_state (cpu=cpu@entry=0x55de1e915cb0, retaddr=retaddr@entry=94412445741769) at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:350 +#5 0x000055de1c4658d0 in handle_cpu_signal (old_set=0x7ffe5ffd8ea8, is_write=0, address=0, pc=94412445741767) + at /media/develdata/devel/build/qemu-2.9.0/user-exec.c:124 +#6 cpu_mips_signal_handler (host_signum=host_signum@entry=11, pinfo=pinfo@entry=0x7ffe5ffd8eb0, puc=puc@entry=0x7ffe5ffd8d80) + at /media/develdata/devel/build/qemu-2.9.0/user-exec.c:229 +#7 0x000055de1c4803be in host_signal_handler (host_signum=11, info=0x7ffe5ffd8eb0, puc=0x7ffe5ffd8d80) + at /media/develdata/devel/build/qemu-2.9.0/linux-user/signal.c:646 +#8 <signal handler called> +#9 __bswap_32 (__bsx=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/byteswap.h:47 +#10 bswap32 (x=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/bswap.h:21 +#11 ldl_be_p (ptr=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/bswap.h:434 +#12 cpu_ldl_code (env=0x55de1e91df48, ptr=0) at /media/develdata/devel/build/qemu-2.9.0/include/exec/cpu_ldst_useronly_template.h:68 +#13 gen_intermediate_code (env=env@entry=0x55de1e91df48, tb=tb@entry=0x7f1e7b288e58) + at /media/develdata/devel/build/qemu-2.9.0/target/mips/translate.c:19962 +#14 0x000055de1c4352e6 in tb_gen_code (cpu=cpu@entry=0x55de1e915cb0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=162, cflags=<optimized out>, + cflags@entry=0) at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:1295 +#15 0x000055de1c436a7a in tb_find (tb_exit=0, last_tb=0x0, cpu=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/cpu-exec.c:365 +#16 cpu_exec (cpu=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/cpu-exec.c:673 +#17 0x000055de1c466278 in cpu_loop (env=0x55de1e91df48) at /media/develdata/devel/build/qemu-2.9.0/linux-user/main.c:2236 +#18 0x000055de1c433103 in main (argc=<optimized out>, argv=0x7ffe5ffd9de8, envp=<optimized out>) + at /media/develdata/devel/build/qemu-2.9.0/linux-user/main.c:4860 +(gdb) thread 2 +[Switching to thread 2 (Thread 0x7f1e7d0ad700 (LWP 9727))] +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +38 ../sysdeps/unix/sysv/linux/x86_64/syscall.S: Datei oder Verzeichnis nicht gefunden. +(gdb) where +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x000055de1c527605 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/futex.h:26 +#2 qemu_event_wait (ev=ev@entry=0x55de1e82c124 <rcu_call_ready_event>) at /media/develdata/devel/build/qemu-2.9.0/util/qemu-thread-posix.c:399 +#3 0x000055de1c52d41e in call_rcu_thread (opaque=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/util/rcu.c:249 +#4 0x00007f1e7d6ef6ba in start_thread (arg=0x7f1e7d0ad700) at pthread_create.c:333 +#5 0x00007f1e7d4253dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1708077 b/results/classifier/gemma3:12b/debug/1708077 new file mode 100644 index 000000000..4ffab34fd --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1708077 @@ -0,0 +1,4 @@ + +PPC interrupt exception！ + +There is a exception on interrupt system when run the system with debug app on qemu-system-ppc.exe。I have try in version SHA-1: 2421f381dc38a8a6d12477c08c2f74a35a0698f8 no problem，but the next version SHA-1: 28f997a82cb509bf4775d4006b368e1bde8b7bdd have this exception。 And I found during this period in the repair of multi-threaded mutex，so I guess whether the PPC has some mutex needed are not taken into account。My english is poor，so there may be many grammatical errors。I hope you can understand the problem I described。 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/171 b/results/classifier/gemma3:12b/debug/171 new file mode 100644 index 000000000..dd7fecee5 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/171 @@ -0,0 +1,2 @@ + +[RFE] option to suppress gemu_log() output diff --git a/results/classifier/gemma3:12b/debug/1713434 b/results/classifier/gemma3:12b/debug/1713434 new file mode 100644 index 000000000..a994c484e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1713434 @@ -0,0 +1,63 @@ + +prom-env-test test aborted and core dumped + +On ppc64le architecture machine the following test case Aborted and Core dumped. + +# tests/prom-env-test --quiet --keep-going -m=quick --GTestLogFD=6 +** +ERROR:tests/libqtest.c:628:qtest_get_arch: assertion failed: (qemu != NULL) +Aborted (core dumped) + +Steps to re-produce: +clone from the git +configure & compile +run the unit tests by 'make check' + +(gdb) bt +#0 0x00003fff9d60eff0 in raise () from /lib64/libc.so.6 +#1 0x00003fff9d61136c in abort () from /lib64/libc.so.6 +#2 0x00003fff9de1aa04 in g_assertion_message () from /lib64/libglib-2.0.so.0 +#3 0x00003fff9de1ab0c in g_assertion_message_expr () from /lib64/libglib-2.0.so.0 +#4 0x000000001000cc30 in qtest_get_arch () at tests/libqtest.c:628 +#5 0x00000000100048f0 in main (argc=5, argv=0x3ffff2145538) at tests/prom-env-test.c:82 +(gdb) i r +r0 0xfa 250 +r1 0x3ffff2144d30 70368510627120 +r2 0x3fff9d7b9900 70367091333376 +r3 0x0 0 +r4 0x12a7 4775 +r5 0x6 6 +r6 0x8 8 +r7 0x1 1 +r8 0x0 0 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +r13 0x3fff9dfa1950 70367099623760 +r14 0x0 0 +r15 0x0 0 +r16 0x0 0 +r17 0x0 0 +r18 0x0 0 +r19 0x0 0 +r20 0x0 0 +r21 0x0 0 +r22 0x0 0 +r23 0x0 0 +r24 0x0 0 +r25 0x0 0 +r26 0x0 0 +r27 0x100287f8 268601336 +r28 0x16841b40 377756480 +r29 0x4c 76 +r30 0x3ffff2144de8 70368510627304 +r31 0x6 6 +pc 0x3fff9d60eff0 0x3fff9d60eff0 <raise+96> +msr 0x900000000280f033 10376293541503627315 +cr 0x42000842 1107298370 +lr 0x3fff9d61136c 0x3fff9d61136c <abort+396> +ctr 0x0 0 +xer 0x0 0 +orig_r3 0x12a7 4775 +trap 0xc00 3072 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1713516 b/results/classifier/gemma3:12b/debug/1713516 new file mode 100644 index 000000000..01a62545b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1713516 @@ -0,0 +1,81 @@ + +qemu crashes with "GLib-ERROR **: gmem.c" error when a negative value passed to smp threads, cores + +After fixing other bug, +https://bugs.launchpad.net/qemu/+bug/1713408 +with the proposed patch +http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg05357.html + +When tried smp core and thread as negative numbers seeing the following similar error. There is a need to fix for the following. + +Instead of fixing it for every variable/argument. Is there a common place to fix all of these issues? + + +cloned today's git (i.e. 28th Aug 2017) + +# ppc64-softmmu/qemu-system-ppc64 --nographic -vga none -machine pseries,accel=kvm,kvm-type=HV -m size=200g -device virtio-blk-pci,drive=rootdisk -drive file=/home/nasastry/avocado-fvt-wrapper/data/avocado-vt/images/pegas-1.0-ppc64le.qcow2,if=none,cache=none,id=rootdisk,format=qcow2 -monitor telnet:127.0.0.1:1234,server,nowait -net nic,model=virtio -net user -device nec-usb-xhci -smp 8,cores=-1,threads=-1,maxcpus=12 + +(process:27477): GLib-ERROR **: gmem.c:130: failed to allocate 18446744073709550568 bytes +Trace/breakpoint trap + +[New Thread 0x3fffb63deb60 (LWP 27731)] +[New Thread 0x3fffb5aceb60 (LWP 27734)] + +(process:27726): GLib-ERROR **: gmem.c:130: failed to allocate 18446744073709550568 bytes + +Program received signal SIGTRAP, Trace/breakpoint trap. +0x00003fffb75e5408 in raise () from /lib64/libpthread.so.0 +Missing separate debuginfos, use: debuginfo-install glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libgcc-4.8.5-16.el7.ppc64le libstdc++-4.8.5-16.el7.ppc64le ncurses-libs-5.9-13.20130511.el7.ppc64le nss-3.28.4-8.el7.ppc64le nss-softokn-freebl-3.28.3-6.el7.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le +(gdb) bt +#0 0x00003fffb75e5408 in raise () from /lib64/libpthread.so.0 +#1 0x00003fffb796be9c in _g_log_abort () from /lib64/libglib-2.0.so.0 +#2 0x00003fffb796d4c4 in g_log_default_handler () from /lib64/libglib-2.0.so.0 +#3 0x00003fffb796d86c in g_logv () from /lib64/libglib-2.0.so.0 +#4 0x00003fffb796db00 in g_log () from /lib64/libglib-2.0.so.0 +#5 0x00003fffb796b694 in g_malloc0 () from /lib64/libglib-2.0.so.0 +#6 0x000000001018fa84 in spapr_possible_cpu_arch_ids (machine=0x111651e0) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:3322 +#7 0x000000001018b444 in spapr_init_cpus (spapr=0x111651e0) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:2096 +#8 0x000000001018bc6c in ppc_spapr_init (machine=0x111651e0) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:2275 +#9 0x000000001041ca80 in machine_run_board_init (machine=0x111651e0) at hw/core/machine.c:760 +#10 0x0000000010377284 in main (argc=22, argv=0x3ffffffff128, envp=0x3ffffffff1e0) at vl.c:4638 +(gdb) i r +r0 0xfa 250 +r1 0x3fffffffe470 70368744170608 +r2 0x3fffb7608100 70367525765376 +r3 0x0 0 +r4 0x6c4e 27726 +r5 0x5 5 +r6 0x0 0 +r7 0x3fffa8000020 70367267782688 +r8 0x6c4e 27726 +r9 0x0 0 +r10 0x0 0 +r11 0x0 0 +r12 0x0 0 +r13 0x3fffb64fccb0 70367507893424 +r14 0x0 0 +r15 0x0 0 +r16 0x0 0 +r17 0x0 0 +r18 0x1 1 +r19 0x0 0 +r20 0x3fffb796d3f0 70367529325552 +r21 0x0 0 +r22 0x20000000 536870912 +r23 0x1 1 +r24 0x3fffb7a61498 70367530325144 +r25 0x3fffb7a614e8 70367530325224 +r26 0x3fffb7a61488 70367530325128 +r27 0x3fffa80008c0 70367267784896 +r28 0x3fffb79cd2a8 70367529718440 +r29 0x3fffb79cd2a8 70367529718440 +r30 0xffffffffffffffff 18446744073709551615 +r31 0x1 1 +pc 0x3fffb75e5408 0x3fffb75e5408 <raise+56> +msr 0x900000000000d033 10376293541461676083 +cr 0x42244842 1109674050 +lr 0x3fffb796be9c 0x3fffb796be9c <_g_log_abort+60> +ctr 0x0 0 +xer 0x0 0 +orig_r3 0x6c4e 27726 +trap 0xc00 3072 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1715162 b/results/classifier/gemma3:12b/debug/1715162 new file mode 100644 index 000000000..4146fd5ba --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1715162 @@ -0,0 +1,73 @@ + +qemu-user crashing when writing core dump + +I've a binary I'm running in qemux86-64 but it is segfaulting. Whilst qemu writes the core dump for that, qemu itself is segfaulting. + +(gdb) bt full +#0 0x00007efdd962e32e in sigsuspend () from /data/poky-tmp/master/build/sysroots-uninative/x86_64-linux/lib/libc.so.6 +No symbol table info available. +#1 0x0000559176d74da4 in dump_core_and_abort (target_sig=target_sig@entry=11) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:598 + cpu = <optimized out> + env = <optimized out> + ts = 0x55917a42d160 + core_dumped = <optimized out> + act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {18446744067267099647, + 18446744073709551615 <repeats 15 times>}}, sa_flags = 0, sa_restorer = 0x559100004010} +#2 0x0000559176d75a38 in handle_pending_signal (cpu_env=cpu_env@entry=0x55917a41c2a0, sig=sig@entry=11, + k=k@entry=0x55917a42d190) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:6596 + handler = <optimized out> + set = {__val = {4294967297, 4294967297, 94083256460867, 14, 128, 0, 8, 3, 0, 1, 0, 4243635, 139628765215104, + 94083255852784, 94083309703424, 3351315493}} + target_old_set = {sig = {0}} + sa = <optimized out> + ts = 0x55917a42d160 +#3 0x0000559176d765ac in process_pending_signals (cpu_env=<optimized out>) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:6674 + sig = 11 + ts = 0x55917a42d160 + set = {__val = {18446744067267100671, 18446744073709551615 <repeats 15 times>}} + blocked_set = <optimized out> +#4 0x0000559176d5e0d8 in cpu_loop (env=0x55917a41c2a0) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/main.c:369 + trapnr = 14 + pc = <optimized out> + ret = <optimized out> + info = {si_signo = 11, si_errno = 0, si_code = 196609, _sifields = {_pad = {101897450, 192, -647518572, 32509, + 842, 0, 1993519912, 21905, 2051194736, 21905, 1997320506, 21905, 2051195440, 21905, 1993546713, 0, + 12767276, 64, 1997233696, 21905, 42, 0, 1997233824, 21905, 1997320464, 21905, 350755584, -1438022877}, + _kill = {_pid = 101897450, _uid = 192}, _timer = {_timer1 = 101897450, _timer2 = 192}, _rt = { + _pid = 101897450, _uid = 192, _sigval = {sival_int = -647518572, sival_ptr = 139628739274388}}, + _sigchld = {_pid = 101897450, _uid = 192, _status = -647518572, _utime = 842, _stime = 94083252138792}, + _sigfault = {_addr = 824735618282}, _sigpoll = {_band = 101897450, _fd = 192}}} +#5 0x0000559176d2a4b8 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/main.c:4862 + regs1 = {r15 = 0, r14 = 0, r13 = 0, r12 = 0, rbp = 0, rbx = 0, r11 = 0, r10 = 0, r9 = 0, r8 = 0, rax = 0, + rcx = 0, rdx = 0, rsi = 0, rdi = 0, orig_rax = 0, rip = 274888416832, cs = 0, eflags = 0, + rsp = 274888401360, ss = 0} + regs = 0x7ffda5b29fc0 + info1 = {load_bias = 274888413184, load_addr = 274877906944, start_code = 274877906944, + end_code = 274877917360, start_data = 274880015120, end_data = 274880016400, start_brk = 0, + brk = 274880016472, start_mmap = 183251939328, start_stack = 274888401360, stack_limit = 274880024576, + entry = 274888416832, code_offset = 0, data_offset = 0, saved_auxv = 274888402256, + auxv_len = 18446744073709550728, arg_start = 274888401368, arg_end = 274888401408, + arg_strings = 274888402550, env_strings = 274888402788, file_string = 274888413067, elf_flags = 0, + personality = 0} + info = 0x7ffda5b2a070 + bprm = { + buf = "\177ELF\002\001\001\000\000\000\000\000\000\000\000\000\003\000>\000\001\000\000\000@\016\000\000\000\000\000\000@\000\000\000\000\000\000\000\230`\002\000\000\000\000\000\000\000\000\000@\000\070\000\006\000@\000\027\000\026\000\001\000\000\000\005", '\000' <repeats 27 times>, "\264C\002\000\000\000\000\000\264C\002\000\000\000\000\000\000\000 \000\000\000\000\000\001\000\000\000\006\000\000\000\240G\002\000\000\000\000\000\240G\"\000\000\000\000\000\240G\"\000\000\000\000\000\330\027\000\000\000\000\000\000p\031\000\000\000\000\000\000\000\000 \000\000\000\000\000\002\000\000\000\006\000\000\000\030N\002\000\000\000\000\000\030N\"\000\000\000\000\000"..., p = 274888401360, fd = 3, + e_uid = 1000, e_gid = 1000, argc = 5, envc = 104, argv = 0x55917a42d120, envp = 0x55917a42a8f0, + filename = 0x7ffda5b2c683 "/data/poky-tmp/master/build/work/intel_corei7_64-poky-linux/core-image-weston/1.0-r0/rootfs/usr/bin/fc-cache", core_dump = 0x559176d76ed0 <elf_core_dump>} + ts = <optimized out> + env = 0x55917a41c2a0 + cpu = 0x55917a414010 + target_environ = 0x55917a42a8f0 + wrk = 0x55917a42ac30 + target_argv = 0x55917a42d120 + target_argc = 5 + i = <optimized out> + ret = <optimized out> + execfd = <optimized out> + +(I'll reproduce this with glibc debug symbols shortly) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1722 b/results/classifier/gemma3:12b/debug/1722 new file mode 100644 index 000000000..0b374f291 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1722 @@ -0,0 +1,88 @@ + +qemu-mipsn32: Illegal Instruction at `exts` instruction +Description of problem: +Run with the command above, I got this error: + +``` +qemu-mipsn32 run +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` + +I then tried to debug the program with qemu option `-g 1234` and know that + +``` +$ gdb-multiarch run +... + +pwndbg> target remote 0:1234 +... + +pwndbg> c +Continuing. + +Program received signal SIGILL, Illegal instruction. +0x3f7d2434 in ?? () from /lib32/ld.so.1 +warning: GDB can't find the start of the function at 0x3f7d2434. +x/10i + +pwndbg> x/10i $pc +=> 0x3f7d2434: 0x7047f03a + 0x3f7d2438: lui a3,0x7000 + 0x3f7d243c: ori a3,a3,0x5e + 0x3f7d2440: b 0x3f7d241c + 0x3f7d2444: subu v0,a3,v0 + 0x3f7d2448: sltiu a7,a3,-3 + 0x3f7d244c: bnezl a7,0x3f7d246c + 0x3f7d2450: subu a3,a4,v0 + 0x3f7d2454: addiu a3,a3,1 + 0x3f7d2458: li v0,-4 +``` + +So I know the problem is in libc32/ld.so.1. When I dissasemble that file and look at offset 0x4434, it's an `exts` instruction as below: + +``` +$ file /lib32/ld.so.1 +/lib32/ld-2.15.so: ELF 32-bit MSB shared object, MIPS, N32 MIPS64 rel2 version 1 (SYSV), dynamically linked, stripped + +$ ./mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-objdump -d /lib32/ld.so.1 | less + ... + 4434: 7047f03a exts a3,v0,0x0,0x1e + 4438: 3c077000 lui a3,0x7000 + 443c: 34e7005e ori a3,a3,0x5e + 4440: 1000fff6 b 441c <GLIBC_2.0@@GLIBC_2.0+0x441c> + 4444: 00e21023 subu v0,a3,v0 + 4448: 2cebfffd sltiu a7,a3,-3 + 444c: 55600007 bnezl a7,446c <GLIBC_2.0@@GLIBC_2.0+0x446c> + 4450: 01023823 subu a3,a4,v0 + 4454: 24e70001 addiu a3,a3,1 + 4458: 2402fffc li v0,-4 +``` +Steps to reproduce: +1. Download toolchain of mips64-n32 on toolchains.bootlin.com [here](https://toolchains.bootlin.com/releases_mips64-n32.html) +2. Write this c code to file `run.c`: + +```c +#include <stdio.h> + +int main(){ + puts("hello world"); + while (1); +} +``` + +3. Compile file run.c with downloaded toolchain: + +``` +mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-gcc run.c -o run +``` + +> Step 1, 2 and 3 can be skip if you download the attached `run` file. + +4. Download the attached ld +5. Make new dir at `/lib32` and move the file ld to `/lib32` +6. Run command `qemu-mipsn32 run` +Additional information: +[ld-2.15.so](/uploads/95f4da26e42d43d39aa2350670134bb5/ld-2.15.so) + +[run](/uploads/01be57442009a75cf2f59cbcf53474f4/run) diff --git a/results/classifier/gemma3:12b/debug/1724 b/results/classifier/gemma3:12b/debug/1724 new file mode 100644 index 000000000..243e3e231 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1724 @@ -0,0 +1,46 @@ + +qemu-system-riscv64 can't break by gdb +Description of problem: +The qemu-system-riscv64 can't break by gdb. +( => The target is not responding to interrupt requests. +Stop debugging it? (y or n) Quit) + +I using old qemu-system-risc64(7.2) don't has this issue. + +This test case running simple OS(riscv-xv6). +Steps to reproduce: +1.qemu-system-riscv64 -machine virt -bios none -kernel kernel/kernel -m 128M -smp 3 -nographic -global virtio-mmio.force-legacy=false -drive file=fs.img,if=none,format=raw,id=x0 -device virtio-blk- device,drive=x0,bus=virtio-mmio-bus.0 -S -gdb tcp::26000 + + +2.test@test-VirtualBox:~$ riscv64-unknown-linux-gnu-gdb -q +(gdb) target remote :26000 +Remote debugging using :26000 +warning: No executable has been specified and target does not support +determining executable automatically. Try using the "file" command. +0x0000000000001000 in ?? () +(gdb) c +Continuing. + +3.check xv6 is running. +xv6 kernel is booting + +hart 2 starting +hart 1 starting +init: starting sh +$ + +4.Can't stop by GDB. +(gdb) c +Continuing. +^C^CThe target is not responding to interrupt requests. +Stop debugging it? (y or n) Quit +(gdb) +Additional information: +Test on new QEMU. + +``` +commit cab35c73be9d579db105ef73fa8a60728a890098 (HEAD -> master, origin/staging, origin/master, origin/HEAD) +Merge: 48ab886d3d d7ee93e243 +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Jun 20 10:26:53 2023 +0200 +``` diff --git a/results/classifier/gemma3:12b/debug/1724485 b/results/classifier/gemma3:12b/debug/1724485 new file mode 100644 index 000000000..8a0aa8d83 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1724485 @@ -0,0 +1,19 @@ + +Invalid assertion in arm_read_memory_func + +Hi, + +I think there is an invalid assertion in arm_read_memory_func: +assert(info->endian == BFD_ENDIAN_LITTLE) + +I face it in the following use case: target armeb-linux (I use qemu user mode), -d in_asm -cpu any. + +At some point during program startup, glibc's _dl_new_object calls strlen, which is written in thumb2 mode (armv6t2). So print_insn_arm() calls arm_read_memory_func() with length==2, and info->flags == INSN_ARM_BE32, and the assert is false. + +If I remove the assert, execution continues OK. + +With the assert, I get the error message from the assert, and qemu then stalls. + +Can you confirm the assert can be removed? Or if not, explain me how to avoid/fix the subsequent qemu stall? + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1725 b/results/classifier/gemma3:12b/debug/1725 new file mode 100644 index 000000000..8679a786e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1725 @@ -0,0 +1,22 @@ + +qemu-system-x86_64 reports wrong thread to GDB on SIGINT +Description of problem: +Upon interruption of a thread by GDB, QEMU in some circumstances will send a stop reply with the ID of a thread that had not been resumed. + +This happens for the following reasons: +1. GDB uses `vCont` exclusively to resume and step through threads. +2. When a thread is interrupted by GDB, QEMU runs `vm_stop(RUN_STATE_PAUSED)`, which triggers `gdb_vm_state_change`, which, in turn, uses whatever CPU is pointed to by `gdbserver_state.c_cpu` at that time to construct the stop reply. +3. The `vCont` handler in QEMU doesn't set `gdbserver_state.c_cpu` before resuming any CPUs. + +Important to note is that stepping is not affected by this issue because the `EXCP_DEBUG` handler sets `gdbserver_state.c_cpu` to the CPU the exception happened in before `gdb_vm_state_change` runs. Which also means single stepping before continuing is an effective way to work around this bug. +Steps to reproduce: +1. Run QEMU with at least two threads and the GDB stub enabled. +2. Run `gdb --nx --ex 'target remote :1234' --ex 'set scheduler-locking on'` +3. Switch to Thread 1.2 in GDB with `thr 2` +4. Resume Thread 1.2 in GDB with `c` +5. Press Ctrl+C to interrupt the VM +6. Notice that the event is reported as having happened in Thread 1.1, which has not been resumed. +Additional information: +Note that, while this bug happens no matter the state of `scheduler-locking`, it only becomes a problem when it is enabled. This is because, when it is disabled, GDB will always resume all threads on `continue`, so it doesn't matter what thread ID QEMU says the interrupt happened in, as it is guaranteed to have been resumed anyway. That, however, is not the case when `scheduler-locking` is enabled. + +Regardless, I don't think it makes sense for QEMU to be reporting events happening in threads that weren't resumed through either `s/S/c/C` or `vCont`, which is what it's doing here. diff --git a/results/classifier/gemma3:12b/debug/1728660 b/results/classifier/gemma3:12b/debug/1728660 new file mode 100644 index 000000000..fb0c3af8f --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1728660 @@ -0,0 +1,49 @@ + +qemu-io segfaults at block/io.c:2545 + +git is at HEAD a93ece47fd9edbd4558db24300056c9a57d3bcd4 +This is on ppc64le architecture. + +Re-production steps: + +1. Copy the attached file named test.img to a directory +2. And customize the following command to point to the above directory and run the same. +# mv test.img copy.img +# qemu-io <path to>/copy.img -c "discard 108544 97792" + +from gdb: +Program terminated with signal 11, Segmentation fault. +#0 0x00000000100af254 in bdrv_co_pdiscard (bs=0x3ee89ad0, offset=196608, bytes=9728) at block/io.c:2545 +2545 if (bs->drv->bdrv_co_pdiscard) { +Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.26-21.el7.ppc64le glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gmp-6.0.0-15.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le keyutils-libs-1.5.8-3.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libaio-0.3.109-13.el7.ppc64le libcom_err-1.42.9-10.el7.ppc64le libcurl-7.29.0-42.el7.ppc64le libffi-3.0.13-18.el7.ppc64le libgcc-4.8.5-16.el7_4.1.ppc64le libidn-1.28-4.el7.ppc64le libselinux-2.5-11.el7.ppc64le libssh2-1.4.3-10.el7_2.1.ppc64le libstdc++-4.8.5-16.el7_4.1.ppc64le libtasn1-4.10-1.el7.ppc64le nettle-2.7.1-8.el7.ppc64le nspr-4.13.1-1.0.el7_3.ppc64le nss-3.28.4-15.el7_4.ppc64le nss-softokn-freebl-3.28.3-8.el7_4.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le pcre-8.32-17.el7.ppc64le zlib-1.2.7-17.el7.ppc64le +(gdb) bt +#0 0x00000000100af254 in bdrv_co_pdiscard (bs=0x3ee89ad0, offset=196608, bytes=9728) at block/io.c:2545 +#1 0x000000001008f260 in blk_co_pdiscard (blk=0x3ee79410, offset=108544, bytes=97792) at block/block-backend.c:1447 +#2 0x0000000010090884 in blk_pdiscard_entry (opaque=0x3fffd7402c58) at block/block-backend.c:1851 +#3 0x00000000101aa444 in coroutine_trampoline (i0=1055521728, i1=0) at util/coroutine-ucontext.c:79 +#4 0x00003fff7a3d2b9c in makecontext () from /lib64/libc.so.6 +#5 0x0000000000000000 in ?? () +(gdb) bt full +#0 0x00000000100af254 in bdrv_co_pdiscard (bs=0x3ee89ad0, offset=196608, bytes=9728) at block/io.c:2545 + num = 9728 + req = {bs = 0x3ee89ad0, offset = 108544, bytes = 97792, type = BDRV_TRACKED_DISCARD, serialising = false, overlap_offset = 108544, + overlap_bytes = 97792, list = {le_next = 0x0, le_prev = 0x3ee8cd48}, co = 0x3ee9fbc0, wait_queue = {entries = {sqh_first = 0x0, + sqh_last = 0x3fff7823fe10}}, waiting_for = 0x0} + max_pdiscard = 2147467264 + ret = 0 + head = 0 + tail = 9728 + align = 16384 + __PRETTY_FUNCTION__ = "bdrv_co_pdiscard" +#1 0x000000001008f260 in blk_co_pdiscard (blk=0x3ee79410, offset=108544, bytes=97792) at block/block-backend.c:1447 + ret = 0 +#2 0x0000000010090884 in blk_pdiscard_entry (opaque=0x3fffd7402c58) at block/block-backend.c:1851 + rwco = 0x3fffd7402c58 +#3 0x00000000101aa444 in coroutine_trampoline (i0=1055521728, i1=0) at util/coroutine-ucontext.c:79 + arg = {p = 0x3ee9fbc0, i = {1055521728, 0}} + self = 0x3ee9fbc0 + co = 0x3ee9fbc0 +#4 0x00003fff7a3d2b9c in makecontext () from /lib64/libc.so.6 +No symbol table info available. +#5 0x0000000000000000 in ?? () +No symbol table info available. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1736 b/results/classifier/gemma3:12b/debug/1736 new file mode 100644 index 000000000..a44278245 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1736 @@ -0,0 +1,68 @@ + +Invalid guest addr in debug output +Description of problem: +When using QEMU 7.1.0 the log file for the first translation block (not starting at 0) looks like this: +(Note the `guest addr 0x00010000`) +``` +IN: +0x00010000: e1a00000 mov r0, r0 +0x00010004: e1a00000 mov r0, r0 +0x00010008: e1a00000 mov r0, r0 +0x0001000c: e1a00000 mov r0, r0 +0x00010010: e1a00000 mov r0, r0 +0x00010014: e1a00000 mov r0, r0 +0x00010018: e1a00000 mov r0, r0 +0x0001001c: e1a00000 mov r0, r0 +0x00010020: ea000005 b #0x1003c + +OUT: [size=47] + -- guest addr 0x00010000 + tb prologue +0x7f95a8000300: 8b 5d f0 movl -0x10(%rbp), %ebx +0x7f95a8000303: 85 db testl %ebx, %ebx +0x7f95a8000305: 0f 8c 18 00 00 00 jl 0x7f95a8000323 + -- guest addr 0x00010020 +0x7f95a800030b: e9 00 00 00 00 jmp 0x7f95a8000310 +0x7f95a8000310: c7 45 3c 3c 00 01 00 movl $0x1003c, 0x3c(%rbp) +0x7f95a8000317: 48 8d 05 22 ff ff ff leaq -0xde(%rip), %rax +0x7f95a800031e: e9 f5 fc ff ff jmp 0x7f95a8000018 +0x7f95a8000323: 48 8d 05 19 ff ff ff leaq -0xe7(%rip), %rax +0x7f95a800032a: e9 e9 fc ff ff jmp 0x7f95a8000018 +``` + +For QEMU 7.2.0 and higher: +(Note the `guest addr` is only the page offset.) +``` +Trace 0: 0x7fe434000100 [00000400/00000000/00000020/ff200000] +---------------- +IN: +0x00010000: e1a00000 mov r0, r0 +0x00010004: e1a00000 mov r0, r0 +0x00010008: e1a00000 mov r0, r0 +0x0001000c: e1a00000 mov r0, r0 +0x00010010: e1a00000 mov r0, r0 +0x00010014: e1a00000 mov r0, r0 +0x00010018: e1a00000 mov r0, r0 +0x0001001c: e1a00000 mov r0, r0 +0x00010020: ea000005 b #0x1003c + +OUT: [size=52] + -- guest addr 0x00000000 + tb prologue +0x7fe434000340: 8b 5d f0 movl -0x10(%rbp), %ebx +0x7fe434000343: 85 db testl %ebx, %ebx +0x7fe434000345: 0f 8c 1d 00 00 00 jl 0x7fe434000368 + -- guest addr 0x00000020 +0x7fe43400034b: 8b 5d 3c movl 0x3c(%rbp), %ebx +0x7fe43400034e: 83 c3 3c addl $0x3c, %ebx +0x7fe434000351: 89 5d 3c movl %ebx, 0x3c(%rbp) +0x7fe434000354: 66 66 90 nop +0x7fe434000357: e9 00 00 00 00 jmp 0x7fe43400035c +0x7fe43400035c: 48 8d 05 1d ff ff ff leaq -0xe3(%rip), %rax +0x7fe434000363: e9 b0 fc ff ff jmp 0x7fe434000018 +0x7fe434000368: 48 8d 05 14 ff ff ff leaq -0xec(%rip), %rax +0x7fe43400036f: e9 a4 fc ff ff jmp 0x7fe434000018 +``` +Steps to reproduce: +1. Run the provided command line for any kernel / system image. (likely other architectures are affected as well) +2. Look into the debug log. +Additional information: +While looking if this was already reported I found #1528 and #1697 which could potentially caused by this. It might as well be just an oversight in the debug output. diff --git a/results/classifier/gemma3:12b/debug/1746943 b/results/classifier/gemma3:12b/debug/1746943 new file mode 100644 index 000000000..d3b23ecdc --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1746943 @@ -0,0 +1,11 @@ + +qemu-aarch64-static: qemu: uncaught target signal 11 for ps/top cmd + +In a docker container created from an aarch64 image, injects qemu-aarch64-static (in /usr/bin) + run ps/top cmd inside this container + + reports "qemu: uncaught target signal 11 (Segmentation fault)" + +Tried qemu-aarch64-static from fedora 27 / ubuntu artful / debian unstable (i.e. qemu version 2.10 - 2.11) + +The aarch64 dock image is fedora 27(and with qemu-aarch64-static Fedora 27), hence I opened a related bug here https://bugzilla.redhat.com/show_bug.cgi?id=1541252 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1748612 b/results/classifier/gemma3:12b/debug/1748612 new file mode 100644 index 000000000..c268be4f5 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1748612 @@ -0,0 +1,16 @@ + +qemu-user option -strace -D <file> doesn't work + +I have been trying to access qemu -strace output from a script +The main problem was it was on stderr, the strace output was merged with my program's stderr output. +Then I tried to use the -D option, to log the output to a file. +This didn't work even if the log file was created, but it was empty. + +I have looked at the source code and found the print function was not qemu_log with -strace but gemu_log (to be clear it was GEMU NOT QEMU) + + +I have then replaced all gemu_log by qemu_log removed declaration of gemu_log and recompiled, it seems to works just fine right now. + +removed declaration here and here: +https://github.com/qemu/qemu/blob/master/linux-user/main.c#L108 +https://github.com/qemu/qemu/blob/master/linux-user/qemu.h#L203 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1749 b/results/classifier/gemma3:12b/debug/1749 new file mode 100644 index 000000000..70904da02 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1749 @@ -0,0 +1,21 @@ + +[Riscv-fu540] UEFI cannot be started with gdb on sifive fu540 platform？ +Description of problem: +Using qemu start UEFI on sifive fu540 platform with option： -S -s. +``` +qemu-system-riscv64 \ + -cpu sifive-u54 -machine sifive_u \ + -bios U540.fd \ + -m 2048 -nographic -smp cpus=2,maxcpus=2 \ + -S -s +``` +UEFI url is： https://github.com/tianocore/edk2.git +Steps to reproduce: +1. start qemu with -S -s param in one terminal +2. riscv64-unknown-linux-gnu-gdb in other terminal +3. in gdb terminal: +``` + target remove :1234 + c +``` +4. in qemu terminal, there has no any output ? diff --git a/results/classifier/gemma3:12b/debug/1756927 b/results/classifier/gemma3:12b/debug/1756927 new file mode 100644 index 000000000..854bb3e0a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1756927 @@ -0,0 +1,19 @@ + +ARMv7 LPAE: IFSR doesn't have the LPAE bit in case of BKPT + +When a user application triggers a 'bkpt' instruction while LPAE is used, the bit [9] of IFSR is not correctly set during the prefetch abort exception. + +You'll find attached a minimal example to reproduce the issue (just run 'make all'). +The output I get is: + +supervisor +user +prefetch +short-descriptor + +The last entry should read 'long-descriptor'. + + +Qemu revision: 48ae1f60d8c9a770e6da64407984d84e25253c69 +Ubuntu verison: 16.04 LTS +Cross Compiler: gcc linaro 6.3.1-2017.02-x86_64_arm-eabi \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1761535 b/results/classifier/gemma3:12b/debug/1761535 new file mode 100644 index 000000000..cc35ccf65 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1761535 @@ -0,0 +1,37 @@ + +qemu-aarch64-static docker arm64v8/openjdk coredump + +I am using qemu-aarch64-static to run the arm64v8/openjdk official image on my x86 machine. Using QEMU master, I immediately hit a bug which hangs the container. With Ubuntu default version qemu-aarch64 version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24) and qemu-aarch64 version 2.11.1 (v2.11.1-dirty) the hang does not take place. + +To reproduce (and get to the core dump): + +$ /tmp/tmptgyg3nvh/qemu-aarch64-static/qemu-aarch64-static -version +qemu-aarch64 version 2.11.91 (v2.12.0-rc1-5-g47d3b60-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +$ docker run -it -v /tmp/tmptgyg3nvh/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/openjdk /bin/bash +root@bf75cf45d311:/# javac +Usage: javac <options> <source files> +where possible options include: + -g Generate all debugging info +<...snip...> + @<filename> Read options and filenames from file + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +...TERMINAL HANGS... + + +To get the core dump, In a separate terminal: + +# snapshot the file system of the hung image +$ docker commit $(docker ps -aqf "name=latest_qemu") qemu_coredump + +# connect with known working qemu +$ docker run -t -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -i qemu_coredump /bin/bash + +$$ ls -lat +total 10608 +<snip> +-rw-r--r-- 1 root root 10792960 Mar 29 18:02 qemu_bash_20180329-180251_1.core +drwxrwxrwt 5 root root 4096 Mar 29 18:02 tmp +<snip> \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1762179 b/results/classifier/gemma3:12b/debug/1762179 new file mode 100644 index 000000000..8ca0a5b5f --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1762179 @@ -0,0 +1,78 @@ + +Record and replay replay fails with: "ERROR:replay/replay-time.c:49:replay_read_clock: assertion failed" + +QEMU master at 08e173f29461396575c85510eb41474b993cb1fb + +QEMU commands: + + +``` +#!/usr/bin/env bash +cmd="\ +time \ +./out/x86_64/buildroot/host/usr/bin/qemu-system-x86_64 \ +-M pc \ +-append 'root=/dev/sda console=ttyS0 nokaslr printk.time=y - lkmc_eval=\"/rand_check.out;/sbin/ifup -a;wget -S google.com;/poweroff.out;\"' \ +-kernel 'out/x86_64/buildroot/images/bzImage' \ +-nographic \ +\ +-drive file=out/x86_64/buildroot/images/rootfs.ext2.qcow2,if=none,id=img-direct,format=qcow2 \ +-drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \ +-device ide-hd,drive=img-blkreplay \ +\ +-netdev user,id=net1 \ +-device rtl8139,netdev=net1 \ +-object filter-replay,id=replay,netdev=net1 \ +" +echo "$cmd" +eval "$cmd -icount 'shift=7,rr=record,rrfile=replay.bin'" +eval "$cmd -icount 'shift=7,rr=replay,rrfile=replay.bin'" +``` + +Images uploaded to: https://github.com/cirosantilli/linux-kernel-module-cheat/releases/download/test-replay-arm/images4.zip + +The replay failed straight out with: + +``` +ERROR:replay/replay-time.c:49:replay_read_clock: assertion failed: (replay_file && replay_mutex_locked()) +``` + +Images generated with: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/9513c162ef57e6cb70006dfe870856f94ee9a133 + +QEMU configure: + +``` +cd /home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/build/host-qemu-custom; PATH="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin:/home/ciro/bak/git/linux-kernel-modul +e-cheat/out/x86_64/buildroot/host/sbin:./node_modules/.bin:/usr/local/heroku/bin:/home/ciro/android-sdk/platform-tools:/home/ciro/android-sdk/tools:/home/ciro/android-studio//bin:/home/ciro/android-sdk/ndk-bundl +e:/home/ciro/android-sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin:/home/ciro/bak/git/devbin:/home/ciro/bin:/usr/local/texlive/2013/bin/x86_64-linux:/home/ciro/.rvm/gems/ruby-2.4. +1/bin:/home/ciro/.rvm/gems/ruby-2.4.1@global/bin:/home/ciro/.rvm/rubies/ruby-2.4.1/bin:./node_modules/.bin:/usr/local/heroku/bin:/home/ciro/android-sdk/platform-tools:/home/ciro/android-sdk/tools:/home/ciro/andr +oid-studio//bin:/home/ciro/android-sdk/ndk-bundle:/home/ciro/android-sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin:/home/ciro/bak/git/devbin:/home/ciro/bin:/usr/local/texlive/2013 +/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/bin:/snap/bin:/home/ciro/bak/git/latex:/home/ciro/.rvm/bin:/home/ciro/anaconda2/bin:/home/ciro/.cab +al/bin:/bin:/home/ciro/.go/bin:/home/ciro/.local/bin/:/home/ciro/bak/git/runlinux:/usr/bin:/home/ciro/bak/git/latex:/home/ciro/.rvm/bin:/home/ciro/anaconda2/bin:/home/ciro/.cabal/bin:/bin:/home/ciro/.go/bin:/home/ciro/.local/bin/:/home/ciro/bak/git/runlinux" PKG_CONFIG="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/pkg-config" PKG_CONFIG_SYSROOT_DIR="/" PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 PKG_ +CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_LIBDIR="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/lib/pkgconfig:/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/share/pkg +config" AR="/usr/bin/ar" AS="/usr/bin/as" LD="/usr/bin/ld" NM="/usr/bin/nm" CC="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/ccache /usr/bin/gcc" GCC="/home/ciro/bak/git/linux-kerne +l-module-cheat/out/x86_64/buildroot/host/bin/ccache /usr/bin/gcc" CXX="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/ccache /usr/bin/g++" CPP="/usr/bin/cpp" OBJCOPY="/usr/bin/objcopy +" RANLIB="/usr/bin/ranlib" CPPFLAGS="-I/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/include" CFLAGS="-O2 -I/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/include +" CXXFLAGS="-O2 -I/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/include" LDFLAGS="-L/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/lib -Wl,-rpath,/home/ciro/bak/g +it/linux-kernel-module-cheat/out/x86_64/buildroot/host/lib" INTLTOOL_PERL=/usr/bin/perl CPP="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/ccache /usr/bin/gcc -E" ./configure --targe +t-list="x86_64-softmmu" --prefix="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host" --interp-prefix=/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/x86_64-buildroot-l +inux-uclibc/sysroot --cc="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/ccache /usr/bin/gcc" --host-cc="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/cca +che /usr/bin/gcc" --python=/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin/python2 --extra-cflags="-O2 -I/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/include" + --extra-ldflags="-L/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/lib -Wl,-rpath,/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/lib" --enable-debug --extra-cflags +=-DDEBUG_PL061=1 --enable-trace-backends=simple --enable-sdl --with-sdlabi=2.0 +``` + +QEMU build: + +``` +PATH="/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/bin:/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/sbin:./node_modules/.bin:/usr/local/heroku/bin:/home/ciro/a +ndroid-sdk/platform-tools:/home/ciro/android-sdk/tools:/home/ciro/android-studio//bin:/home/ciro/android-sdk/ndk-bundle:/home/ciro/android-sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_6 +4/bin:/home/ciro/bak/git/devbin:/home/ciro/bin:/usr/local/texlive/2013/bin/x86_64-linux:/home/ciro/.rvm/gems/ruby-2.4.1/bin:/home/ciro/.rvm/gems/ruby-2.4.1@global/bin:/home/ciro/.rvm/rubies/ruby-2.4.1/bin:./node +_modules/.bin:/usr/local/heroku/bin:/home/ciro/android-sdk/platform-tools:/home/ciro/android-sdk/tools:/home/ciro/android-studio//bin:/home/ciro/android-sdk/ndk-bundle:/home/ciro/android-sdk/ndk-bundle/toolchain +s/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin:/home/ciro/bak/git/devbin:/home/ciro/bin:/usr/local/texlive/2013/bin/x86_64-linux:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/us +r/local/games:/usr/bin:/snap/bin:/home/ciro/bak/git/latex:/home/ciro/.rvm/bin:/home/ciro/anaconda2/bin:/home/ciro/.cabal/bin:/bin:/home/ciro/.go/bin:/home/ciro/.local/bin/:/home/ciro/bak/git/runlinux:/usr/bin:/h +ome/ciro/bak/git/latex:/home/ciro/.rvm/bin:/home/ciro/anaconda2/bin:/home/ciro/.cabal/bin:/bin:/home/ciro/.go/bin:/home/ciro/.local/bin/:/home/ciro/bak/git/runlinux" PKG_CONFIG="/home/ciro/bak/git/linux-kernel-m +odule-cheat/out/x86_64/buildroot/host/bin/pkg-config" PKG_CONFIG_SYSROOT_DIR="/" PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_LIBDIR="/home/ciro/bak/git/linux-kernel-module-cheat/ou +t/x86_64/buildroot/host/lib/pkgconfig:/home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroot/host/share/pkgconfig" /usr/bin/make -j8 -C /home/ciro/bak/git/linux-kernel-module-cheat/out/x86_64/buildroo +t/build/host-qemu-custom +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1766 b/results/classifier/gemma3:12b/debug/1766 new file mode 100644 index 000000000..369058673 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1766 @@ -0,0 +1,4 @@ + +-strace should print target program counter when SIGSEGV +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/1766896 b/results/classifier/gemma3:12b/debug/1766896 new file mode 100644 index 000000000..bbc189241 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1766896 @@ -0,0 +1,162 @@ + +qemu-system-arm segfault in arm_v7m_mmu_idx_for_secstate + +Attempting to emulate some baremetal ARM cortex-M* firmware with gdb causes a segfault every time. + +qemu invocation: +qemu-system-arm -machine none -cpu cortex-m3 -nographic -monitor null -serial null -s -S -device loader,file=firmware.elf + +qemu seems to startup fine with that command. Segfault happens as soon as I connect from another console with + +arm-none-eabi-gdb firmware.elf +> target remote localhost:1234 +# qemu segfaults, and kills arm-none-eabi-gdb along with it + +Here's a bt from qemu-system-arm : + +********************************* +#0 armv7m_nvic_neg_prio_requested (opaque=0x0, secure=false) + at /home/sac/qemu/src/qemu/hw/intc/armv7m_nvic.c:383 + s = 0x0 +#1 0x006e4806 in arm_v7m_mmu_idx_for_secstate (secstate=<optimized out>, env=0xb620263c) + at /home/sac/qemu/src/qemu/target/arm/cpu.h:2345 + el = <optimized out> + mmu_idx = ARMMMUIdx_MPriv + el = <optimized out> + mmu_idx = <optimized out> +#2 cpu_mmu_index (ifetch=false, env=0xb620263c) at /home/sac/qemu/src/qemu/target/arm/cpu.h:2358 + mmu_idx = <optimized out> + el = <optimized out> + ifetch = <optimized out> + env = 0xb620263c + el = <optimized out> + mmu_idx = <optimized out> + el = <optimized out> + el = <optimized out> + mmu_idx = <optimized out> +#3 arm_cpu_get_phys_page_attrs_debug (cs=0xb61fe480, addr=0, attrs=0xbfffc668) + at /home/sac/qemu/src/qemu/target/arm/helper.c:9858 + cpu = 0xb61fe480 + __func__ = "arm_cpu_get_phys_page_attrs_debug" + env = 0xb620263c + phys_addr = 6402535376434480864 + page_size = 5 + prot = -1239242724 + ret = <optimized out> + fsr = 4294967041 + fi = {s2addr = 0, stage2 = false, s1ptw = false, ea = false} + mmu_idx = <optimized out> +#4 0x005729d1 in cpu_get_phys_page_attrs_debug (attrs=<optimized out>, addr=<optimized out>, + cpu=<optimized out>) at /home/sac/qemu/src/qemu/include/qom/cpu.h:580 + cc = <optimized out> + cc = <optimized out> +#5 cpu_memory_rw_debug (cpu=0xb61fe480, addr=0, buf=0xbfffd6dc "", len=4, is_write=0) + at /home/sac/qemu/src/qemu/exec.c:3524 + asidx = <optimized out> + attrs = {unspecified = 0, secure = 0, user = 0, requester_id = 15525} + l = <optimized out> + phys_addr = <optimized out> + page = 0 + __PRETTY_FUNCTION__ = "cpu_memory_rw_debug" +#6 0x005b4c5e in target_memory_rw_debug (is_write=false, len=4, buf=<optimized out>, addr=0, + cpu=0xb61fe480) at /home/sac/qemu/src/qemu/gdbstub.c:56 + cc = <optimized out> + cc = <optimized out> +#7 gdb_handle_packet (s=s@entry=0xb6229800, line_buf=line_buf@entry=0xb6229810 "m0,4") + at /home/sac/qemu/src/qemu/gdbstub.c:1109 + cpu = <optimized out> + cc = <optimized out> + p = 0xb6229813 "4" + thread = <optimized out> + ch = <optimized out> + reg_size = <optimized out> + type = <optimized out> + res = <optimized out> + buf = "m1\000", '\060' <repeats 109 times>, "ffffffff00000000d3010040\000t modification,\n are permitted in any medium without royalt"... + mem_buf = '\000' <repeats 56 times>, "\377\377\377\377\000\000\000\000\323\001\000@", '\000' <repeats 716 times>... + registers = <optimized out> + addr = 0 + len = 4 + __func__ = "gdb_handle_packet" +#8 0x005b55b3 in gdb_read_byte (ch=100, s=0xb6229800) at /home/sac/qemu/src/qemu/gdbstub.c:1664 + reply = 43 '+' + reply = <optimized out> + repeat = <optimized out> +#9 gdb_chr_receive (opaque=<optimized out>, buf=<optimized out>, size=<optimized out>) + at /home/sac/qemu/src/qemu/gdbstub.c:1868 + i = <optimized out> +#10 0x00980319 in tcp_chr_read (chan=0xb6c86200, cond=G_IO_IN, opaque=0xb63fc6e0) + at chardev/char-socket.c:440 + chr = <optimized out> + __func__ = "tcp_chr_read" + s = 0xb63fc6e0 + buf = "$m0,4#fddInfo#c8read:arm-core.xml:0,ffb#08+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df\363\377\377\000\000\000\000\274\354\377\277", '\000' <repeats 16 times>, "\272\356\377 \274\354\377\277", '\000' <repeats 16 times>, "\373\377\377\377\005\000\000\000"... + len = <optimized out> + size = <optimized out> +#11 0xb7808c44 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +No symbol table info available. +#12 0x009e14d2 in glib_pollfds_poll () at util/main-loop.c:214 + context = 0xb645f740 + pfds = <optimized out> + context = <optimized out> + pfds = <optimized out> +#13 os_host_main_loop_wait (timeout=<optimized out>) at util/main-loop.c:261 + context = 0xb645f740 + ret = 1 + spin_counter = 0 + context = <optimized out> + ret = <optimized out> + spin_counter = 0 + notified = false +#14 main_loop_wait (nonblocking=0) at util/main-loop.c:515 + ret = <optimized out> + timeout = 1000 + timeout_ns = <optimized out> +#15 0x00561781 in main_loop () at vl.c:1995 +No locals. +#16 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4911 + i = <optimized out> + snapshot = <optimized out> + linux_boot = <optimized out> + initrd_filename = <optimized out> + kernel_filename = <optimized out> + kernel_cmdline = <optimized out> + boot_order = <optimized out> + boot_once = <optimized out> + ds = <optimized out> + cyls = <optimized out> + heads = <optimized out> + secs = <optimized out> + translation = <optimized out> + opts = <optimized out> + machine_opts = <optimized out> + hda_opts = <optimized out> + icount_opts = <optimized out> + accel_opts = <optimized out> + olist = <optimized out> + optind = 14 + optarg = 0xbffffcf6 "loader,file=firmware.elf" + loadvm = <optimized out> + machine_class = <optimized out> + cpu_model = <optimized out> + vga_model = <optimized out> + qtest_chrdev = <optimized out> + qtest_log = <optimized out> + pid_file = <optimized out> + incoming = <optimized out> + userconfig = <optimized out> + nographic = <optimized out> + display_type = <optimized out> + display_remote = <optimized out> + log_mask = <optimized out> + log_file = <optimized out> + trace_file = <optimized out> + maxram_size = <optimized out> + ram_slots = <optimized out> + vmstate_dump_file = <optimized out> + main_loop_err = 0x0 + err = 0x0 + list_data_dirs = <optimized out> + dirs = <optimized out> + bdo_queue = {sqh_first = 0x0, sqh_last = 0xbffff918} + __func__ = "main" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1773743 b/results/classifier/gemma3:12b/debug/1773743 new file mode 100644 index 000000000..a09b6f459 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1773743 @@ -0,0 +1,22 @@ + +qemu-user -g xxx -E LD_PROFILE=xxx segfault + +Here is two simple steps to reproduce the bug: + +$ qemu-x86_64 -E LD_PROFILE=libc.so.6 -E LD_PROFILE_OUTPUT=. -g 12345 -L / /bin/ls + +(libc.so and /bin/ls might change on your system, in this case we just need a binary with a profilable needed library) + +In a other window launch: + +$ gdb +(gdb) target remote :12345 +(gdb) c + +At this point qemu will segfault. + +It seems this problem is appends when sigprof passed to gdb. +One way I have found to bypass this: +patch gdbstub.c gdb_handlesig and ignore sig if +sig == TARGET_SIGPROF +(which means now I can't catch sigprof on gdb anymore) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1774149 b/results/classifier/gemma3:12b/debug/1774149 new file mode 100644 index 000000000..cc2818941 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1774149 @@ -0,0 +1,77 @@ + +qemu-user x86_64 x86 gdb call function from gdb doesn't work + +While running qemu user x86_64 x86 with gdb server, calling functions are not working. + +Here is how to reproduce it: + +run in a terminal: +$ qemu-x86_64 -g 12345 -L / /bin/ls + +In another terminal run gdb: +(gdb) file /bin/ls +(gdb) target remote :12345 +(gdb) b _init +(gdb) c +(gdb) call malloc(1) +Could not fetch register "fs_base"; remote failure reply 'E14' + +In other cases we also got the error: +Could not fetch register "orig_rax"; remote failure reply 'E14' + +Here is how I patched it (it is only a workaround): + +diff --git a/gdbstub.c b/gdbstub.c +index 2a94030..5749efe 100644 +--- a/gdbstub.c ++++ b/gdbstub.c +@@ -668,6 +668,11 @@ static int gdb_read_register(CPUState *cpu, uint8_t *mem_buf, int reg) + return r->get_reg(env, mem_buf, reg - r->base_reg); + } + } ++#ifdef TARGET_X86_64 ++ return 8; ++#elif TARGET_I386 ++ return 4; ++#endif + return 0; + } + +(Our guess for this issue was, gdb is requesting for 'fake' registers to know register size) + +Once we patched that, we got another problem while calling functions from gdb: We could call functions, but only once. + +Here is how to reproduce it: +run in a terminal: +$ qemu-x86_64 -g 12345 -L / /bin/ls + +In another terminal run gdb: +(gdb) file /bin/ls +(gdb) target remote :12345 +(gdb) b _init +(gdb) c +(gdb) call malloc(1) +$1 = (void *) 0x620010 +(gdb) call malloc(1) +Cannot access memory at address 0x40007ffb8f + +Here is how we patched it to make it work: + +diff --git a/exec.c b/exec.c +index 03238a3..d303922 100644 +--- a/exec.c ++++ b/exec.c +@@ -2833,7 +2833,7 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr, + if (!(flags & PAGE_VALID)) + return -1; + if (is_write) { +- if (!(flags & PAGE_WRITE)) ++ if (!(flags & (PAGE_WRITE | PAGE_WRITE_ORG))) + return -1; + /* XXX: this code should not depend on lock_user */ + if (!(p = lock_user(VERIFY_WRITE, addr, l, 0))) + +From what we saw, there is a page which is passed to read-only after first execution, and gdb need to write on that page to put a breakpoint. (on the stack) + +We suspect this is linked to this: +https://qemu.weilnetz.de/w64/2012/2012-06-28/qemu-tech.html#Self_002dmodifying-code-and-translated-code-invalidation \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1774830 b/results/classifier/gemma3:12b/debug/1774830 new file mode 100644 index 000000000..78f7ffc08 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1774830 @@ -0,0 +1,99 @@ + +qemu monitor disassembled memory dump produces incorrect output + +Greetings, + +I've been using qemu-system-aarch64 to do some low-level programming targeting the raspberry pi 3. While I was debugging a problem in my code I noticed a very confusing inconsistency that I think is very likely a bug somewhere in how qemu's monitor produces it's disassembled output. + +Here's my version output (installed via homebrew on macOS 10.13.4) + +$ qemu-system-aarch64 --version +QEMU emulator version 2.12.0 +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +Some system information (macOS 10.13.4): + +$ uname -a +Darwin Lillith.local 17.5.0 Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT 2018; root:xnu-4570.51.2~1/RELEASE_X86_64 x86_64 + +Here's an example of the problem I am seeing: + +qemu-system-aarch64 -S -M raspi3 -kernel kernel8.img -monitor stdio +QEMU 2.12.0 monitor - type 'help' for more information +(qemu) x /32x 0x80000 +0000000000080000: 0xd53800a1 0x92400421 0xb4000061 0xd503205f +0000000000080010: 0x17ffffff 0x58000161 0x9100003f 0x58000161 +0000000000080020: 0x180000e2 0x34000082 0xf800843f 0x51000442 +0000000000080030: 0x35ffffa2 0xd2806763 0x17ffffff 0x00000000 +0000000000080040: 0x00080000 0x00000000 0x00080050 0x00000000 +0000000000080050: 0x00000000 0x00000000 0x00000000 0x00000000 +0000000000080060: 0x00000000 0x00000000 0x00000000 0x00000000 +0000000000080070: 0x00000000 0x00000000 0x00000000 0x00000000 +(qemu) x /32i 0x80000 +0x00080000: d53800a1 mrs x1, mpidr_el1 +0x00080004: 92400421 and x1, x1, #3 +0x00080008: b4000061 cbz x1, #0x80014 +0x0008000c: d503205f wfe +0x00080010: 17ffffff b #0x8000c +0x00080014: 58000161 ldr x1, #0x80040 +0x00080018: 9100003f mov sp, x1 +0x0008001c: 58000161 ldr x1, #0x80048 +0x00080020: 92400421 and x1, x1, #3 +0x00080024: b4000061 cbz x1, #0x80030 +0x00080028: d503205f wfe +0x0008002c: 17ffffff b #0x80028 +0x00080030: 58000161 ldr x1, #0x8005c +0x00080034: 9100003f mov sp, x1 +0x00080038: 58000161 ldr x1, #0x80064 +0x0008003c: 180000e2 ldr w2, #0x80058 +0x00080040: 34000082 cbz w2, #0x80050 +0x00080044: f800843f str xzr, [x1], #8 +0x00080048: 51000442 sub w2, w2, #1 +0x0008004c: 35ffffa2 cbnz w2, #0x80040 +0x00080050: d2806763 movz x3, #0x33b +0x00080054: 17ffffff b #0x80050 +0x00080058: 00000000 .byte 0x00, 0x00, 0x00, 0x00 +0x0008005c: 00080000 .byte 0x00, 0x00, 0x08, 0x00 +0x00080060: 00000000 .byte 0x00, 0x00, 0x00, 0x00 +0x00080064: 00080050 .byte 0x50, 0x00, 0x08, 0x00 +0x00080068: 00000000 .byte 0x00, 0x00, 0x00, 0x00 +0x0008006c: 00000000 .byte 0x00, 0x00, 0x00, 0x00 +0x00080070: 00000000 .byte 0x00, 0x00, 0x00, 0x00 +0x00080074: 00000000 .byte 0x00, 0x00, 0x00, 0x00 +0x00080078: 00000000 .byte 0x00, 0x00, 0x00, 0x00 +0x0008007c: 00000000 .byte 0x00, 0x00, 0x00, 0x00 + +Please notice that between 0x80004 thru 0x8001c is repeated for some reason in the /32i formatted output which also causes the addresses for the following bytes to also be incorrect. + +Just in order to keep things as clear as possible, I'll also attach the binary shown above but disassembled by objdump instead of qemu. + +$ aarch64-elf-objdump -d kernel8.elf + +kernel8.elf: file format elf64-littleaarch64 + + +Disassembly of section .text: + +0000000000080000 <_start>: + 80000: d53800a1 mrs x1, mpidr_el1 + 80004: 92400421 and x1, x1, #0x3 + 80008: b4000061 cbz x1, 80014 <_start+0x14> + 8000c: d503205f wfe + 80010: 17ffffff b 8000c <_start+0xc> + 80014: 58000161 ldr x1, 80040 <_start+0x40> + 80018: 9100003f mov sp, x1 + 8001c: 58000161 ldr x1, 80048 <_start+0x48> + 80020: 180000e2 ldr w2, 8003c <_start+0x3c> + 80024: 34000082 cbz w2, 80034 <_start+0x34> + 80028: f800843f str xzr, [x1], #8 + 8002c: 51000442 sub w2, w2, #0x1 + 80030: 35ffffa2 cbnz w2, 80024 <_start+0x24> + 80034: d2806763 mov x3, #0x33b // #827 + 80038: 17ffffff b 80034 <_start+0x34> + 8003c: 00000000 .word 0x00000000 + 80040: 00080000 .word 0x00080000 + 80044: 00000000 .word 0x00000000 + 80048: 00080050 .word 0x00080050 + 8004c: 00000000 .word 0x00000000 + +Hopefully this is helpful information, please let me know if I left out anything really important. Thank you! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1775 b/results/classifier/gemma3:12b/debug/1775 new file mode 100644 index 000000000..b66439c5a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1775 @@ -0,0 +1,62 @@ + +QEMU abort on Cortex-M breakpoint exception +Description of problem: +When a breakpoint exception is raised in a ARM Cortex-M board QEMU aborts. + +``` +$ qemu-system-arm --version +QEMU emulator version 8.0.90 (v8.1.0-rc0-21-gd1181d2937) + +$ ./qemu-system-arm -M stm32vldiscovery -nographic -device loader,file=raw-bkpt.hex -d in_asm,exec,int +[...] +Trace 0: 0x7fac6c000100 [00800400/0000000000000100/00000110/ff200000] +---------------- +IN: +0x00000110: be01 bkpt #1 + +Linking TBs 0x7fac6c000100 index 0 -> 0x7fac6c0002c0 +Trace 0: 0x7fac6c0002c0 [00800400/0000000000000110/00000110/ff200000] +qemu-system-arm: ../target/arm/helper.c:12224: arm_security_space_below_el3: Assertion `!arm_feature(env, ARM_FEATURE_M)' failed. +``` + +Expected behavior: +``` +$ qemu-system-arm --version +QEMU emulator version 7.1.0 + +$ ./qemu-system-arm -M stm32vldiscovery -nographic -device loader,file=raw-bkpt.hex -d in_asm,exec,int +[...] +Trace 0: 0x7f5408000100 [00800400/00000100/00000110/ff000000] +---------------- +IN: +0x00000110: be01 bkpt #1 + +Linking TBs 0x7f5408000100 [00000100] index 0 -> 0x7f54080002c0 [00000110] +Trace 0: 0x7f54080002c0 [00800400/00000110/00000110/ff000000] +Taking exception 7 [Breakpoint] on CPU 0 +...BusFault with BFSR.STKERR +...taking pending nonsecure exception 3 +...loading from element 3 of non-secure vector table at 0xc +...loaded new PC 0x0 +---------------- +``` +Steps to reproduce: +1. Run any Cortex-M firmware that raises a breakpoint exception. (minimal example attached) +Additional information: +- Minimal Reproducer: +[raw-bkpt.hex](/uploads/b9289c6f3a4feef015c8a3dffb4fc467/raw-bkpt.hex) +- This is **not** a duplicate of #1658 / #1740 +- Stacktrace: +``` +#2 0x00007ffff5a68538 in abort () at /usr/lib/libc.so.6 +#3 0x00007ffff5a6845c in () at /usr/lib/libc.so.6 +#4 0x00007ffff5a783d6 in () at /usr/lib/libc.so.6 +#5 0x0000555555c55921 in arm_security_space_below_el3 (env=0x555556dc1b40) at ../target/arm/helper.c:12224 +#6 arm_security_space_below_el3 (env=env@entry=0x555556dc1b40) at ../target/arm/helper.c:12222 +#7 0x0000555555c48b08 in arm_is_secure_below_el3 (env=0x555556dc1b40) at ../target/arm/cpu.h:2465 +#8 arm_is_el2_enabled (env=0x555556dc1b40) at ../target/arm/cpu.h:2517 +#9 arm_debug_target_el (env=env@entry=0x555556dc1b40) at ../target/arm/debug_helper.c:24 +#10 0x0000555555c49cb5 in helper_exception_bkpt_insn (env=0x555556dc1b40, syndrome=0xe2000001) at ../target/arm/debug_helper.c:510 +#11 0x00007fffac0002d9 in code_gen_buffer () +[...] +``` diff --git a/results/classifier/gemma3:12b/debug/1777226 b/results/classifier/gemma3:12b/debug/1777226 new file mode 100644 index 000000000..2260e2f69 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1777226 @@ -0,0 +1,16 @@ + +qemu-user warnings confuse userland applications + +I recently observed that warning messages emitted by qemu-user can confuse applications when reading from stdout/stderr. This was observed with the configure script of OpenJDK-11 on qemu-sh4: + +configure: Found potential Boot JDK using configure arguments +configure: Potential Boot JDK found at /usr/lib/jvm/java-10-openjdk-sh4 is incorrect JDK version (qemu: Unsupported syscall: 318); ignoring +configure: (Your Boot JDK version must be one of: 10 11) +configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK +configure exiting with result code 1 + +See: https://buildd.debian.org/status/fetch.php?pkg=openjdk-11&arch=sh4&ver=11%7E18-1&stamp=1529119043&raw=0 + +Commenting out the line of code which emits the warning fixes the problem for me and the configure script finishes without problems. + +Thus, qemu should be modified to avoid cluttering stdout or stderr with its own messages and rather send those warnings to a log file or similar. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1787754 b/results/classifier/gemma3:12b/debug/1787754 new file mode 100644 index 000000000..ab70f71c1 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1787754 @@ -0,0 +1,45 @@ + +qemu sparc -cpu help does not generate correct display + +The output for the "-cpu help" on the Sparc executables is not generating accurate information. + +Running + +./qemu-sparc64 -cpu help + +produces: + +Sparc Fujitsu Sparc64 IU 0004000200000000 FPU 00000000 MMU 00000000 NWINS 4 +Sparc Fujitsu Sparc64 III IU 0004000300000000 FPU 00000000 MMU 00000000 NWINS 5 +Sparc Fujitsu Sparc64 IV IU 0004000400000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc Fujitsu Sparc64 V IU 0004000551000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc TI UltraSparc I IU 0017001040000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc TI UltraSparc II IU 0017001120000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc TI UltraSparc IIi IU 0017001291000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc TI UltraSparc IIe IU 0017001314000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc Sun UltraSparc III IU 003e001434000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc Sun UltraSparc III Cu IU 003e001541000000 FPU 00000000 MMU 00000001 NWINS 8 +Sparc Sun UltraSparc IIIi IU 003e001634000000 FPU 00000000 MMU 00000000 NWINS 8 +Sparc Sun UltraSparc IV IU 003e001831000000 FPU 00000000 MMU 00000002 NWINS 8 +Sparc Sun UltraSparc IV+ IU 003e001922000000 FPU 00000000 MMU 00000000 NWINS 8 +cmt +Sparc Sun UltraSparc IIIi+ IU 003e002200000000 FPU 00000000 MMU 00000001 NWINS 8 +Sparc Sun UltraSparc T1 IU 003e002302000000 FPU 00000000 MMU 00000003 NWINS 8 +hypv +cmt +gl +Sparc Sun UltraSparc T2 IU 003e002402000000 FPU 00000000 MMU 00000003 NWINS 8 +hypv +cmt +gl +Sparc NEC UltraSparc I IU 0022001040000000 FPU 00000000 MMU 00000000 NWINS 8 +Default CPU feature flags (use '-' to remove): float swap mul div flush fsqrt fmul vis1 vis2 fsmuld +Available CPU feature flags (use '+' to add): float128 hypv cmt gl +Numerical features (use '=' to set): iu_version fpu_version mmu_version nwindows + +The entries appear to supposed to be (partial list from source code): + +TI-SuperSparc-II +TI-SuperSparc-II +TI-SuperSparc-II +TI-MicroSparc-I +TI-MicroSparc-I +TI-MicroSparc-I +Sun-UltraSparc-T1 +TI-UltraSparc-IIi +Sun-UltraSparc-T1 + +The output is from qemu 2.12.0. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1790018 b/results/classifier/gemma3:12b/debug/1790018 new file mode 100644 index 000000000..c765163fe --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1790018 @@ -0,0 +1,55 @@ + +Assertion failure (or segmentation fault) running 32-bit x86 Linux guest on 64-bit PowerPC host + +Qemu 2.12.1 (also tried 2.12.0) +Linux gwyn 4.14.48-mc8-easy #1 SMP Sat Jun 30 23:29:01 CDT 2018 ppc64 GNU/Linux +gcc (Adelie 6.4.0-r9) 6.4.0 +GNU assembler (GNU Binutils) 2.30 +musl libc (powerpc64) Version 1.1.19 + +64-bit, 64-thread (16-core) POWER9 server in Big endian mode: +processor : 0 +cpu : POWER9, altivec supported +clock : 3000.000000MHz +revision : 2.2 (pvr 004e 1202) + +Scenario: + +Attempting to install Adélie Linux 32-bit x86 guest on 64-bit PowerPC host using qemu-system-i386. + + +Command line: + +/usr/bin/qemu-system-i386 -cdrom adelie-live-pmmx-1.0-beta1-20180807.iso -hda /dev/gwyn/x86 -m 512 -cpu pentium3 + + +Environment reproduction: + +CD image can be obtained at https://distfiles.adelielinux.org/adelie/1.0-beta1/iso/adelie-live-pmmx-1.0-beta1-20180807.iso +/dev/gwyn/x86 is an LVM2 logical volume, 4 GB in size, on NVMe storage +Qemu was built from sources on this machine, with some distribution patches applied for musl support (does not affect tcg/ppc/* code); patches and build recipe (which was modified: https://bpaste.net/show/1bbb1d07d7f2 for recipe patch) can be found at: https://code.foxkit.us/adelie/packages/blob/master/user/qemu/APKBUILD + + +Without --enable-debug-tcg: + +Thread 5 "qemu-system-i38" received signal SIGSEGV, Segmentation fault. +[Switching to LWP 14090] +0x39fb04787f63db78 in ?? () +(gdb) +(gdb) bt +#0 0x39fb04787f63db78 in () +#1 0x00003ffff1cdb160 in code_gen_buffer () +#2 0x0000000100362048 in cpu_tb_exec (itb=<optimized out>, cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/accel/tcg/cpu-exec.c:169 +#3 0x0000000100362048 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/accel/tcg/cpu-exec.c:626 +#4 0x0000000100362048 in cpu_exec (cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/accel/tcg/cpu-exec.c:734 +#5 0x00000001003211b4 in tcg_cpu_exec (cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/cpus.c:1362 +#6 0x00000001003211b4 in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/cpus.c:1461 +#7 0x00003ffff7fa275c in start (p=0x3fffedb6a810) at src/thread/pthread_create.c:147 +#8 0x00003ffff7fae4c8 in __clone () at src/thread/powerpc64/clone.s:43 + + + +With --enable-debug-tcg: + +Assertion failed: disp == (int16_t) disp (/usr/src/packages/user/qemu/src/qemu-2.12.1/tcg/ppc/tcg-target.inc.c: reloc_pc14_val: 204) +zsh: abort qemu-system-i386 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1792659 b/results/classifier/gemma3:12b/debug/1792659 new file mode 100644 index 000000000..9fbcf84c1 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1792659 @@ -0,0 +1,35 @@ + +watchpoints might not properly stop execution at the right address + +This bug has been tested with the latest development tree (19b599f7664b2ebfd0f405fb79c14dd241557452). + +I am using qemu-system-i386 with the gdbserver stub. I set a watchpoint on some address. When the watchpoint is hit, it will be reported by gdb, but it might happen that eip points to the wrong address (execution has not properly stopped when the watchpoint was hit). + +The setup I used to reproduce it is quite complex, but I believe I have found the cause of the bug, so I will describe that. + +The check_watchpoint() function sets cflags_next_tb in order to force the execution of only one instruction, and then exits the current tb. It then expects to be called again after that one instruction is executed, the watchpoint is hit and it is reported to gdb. + +The problem is that another interrupt might have been generated around the same time as the watchpoint. If the interrupt changes eip and execution goes on in another address, the value of cflags_next_tb will be spoiled. When we come back from the interrupt to the address where the watchpoint is hit, it is possible that a tb with multiple instructions is been executed, and therefore eip points to the wrong address, ahead of where it should be. + +In my case, the order is as follows: +* i8259 generates an IRQ + - cpu->interrupt_request contains both CPU_INTERRUPT_TGT_EXT_1 and CPU_INTERRUPT_HARD +* cpu_handle_interrupt() -> x86_cpu_exec_interrupt() is called + - it deals with CPU_INTERRUPT_TGT_EXT_1 + - execution continues +* I am exactly at the instruction where the watchpoint is hit. + - check_watchpoint() is called and cflags_next_tb is set to force the execution of only one instruction. + - execution breaks out of the loop with siglongjmp() +* cpu_handle_interrupt() -> x86_cpu_exec_interrupt() is called + - it deals with the IRQ. eip is changed and cflags_next_tb is spoiled + - execution continues at the IRQ + +[...] +* The kernel finishes dealing with the IRQ + +* I am back at the instruction where the watchpoint is hit. + - A tb is created and executed with two instructions instead of one + - eip is now ahead of the instruction that hit the watchpoint +* cpu_handle_interrupt() is called + - it deals with CPU_INTERRUPT_DEBUG + - the watchpoint is reported by gdb, but with the wrong eip. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1793539 b/results/classifier/gemma3:12b/debug/1793539 new file mode 100644 index 000000000..680c64e8b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1793539 @@ -0,0 +1,10 @@ + +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5 + +During the build of gedit for RISC-V this error occurs: + +$ qemu-riscv64 -E LD_LIBRARY_PATH=gedit/.libs ./gedit/.libs/gedit +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x600009e4 + +https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/gedit/standard/riscv64 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1795 b/results/classifier/gemma3:12b/debug/1795 new file mode 100644 index 000000000..730207dfc --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1795 @@ -0,0 +1,9 @@ + +PPC: not honouring single stepping through branches and skips a nip +Description of problem: +When debugging in MacsBug, tracing/stepping over any branches (e.g. blt, bgt) will land on the instruction immediately passed the expected address. It appears that branches will execute the target instruction then single step to the next instruction in one go, instead of single stepping to the target instruction. + +For example, if a blt should land on 13371234, stepping over the branch will land on 13371238. The instruction at 13371234 still executes, but this is not the behaviour on a baremetal Mac OS system. +Additional information: +A <a href="https://i.imgur.com/f6dguMt.png">screenshot</a> before the branch. +A <a href="https://imgur.com/WoVDtN7.png">screenshot<a/> after pressing 't' to step over the branch. Note that the PC is now 1E36CAB8 instead of the expected 1E36CAB4. diff --git a/results/classifier/gemma3:12b/debug/1805445 b/results/classifier/gemma3:12b/debug/1805445 new file mode 100644 index 000000000..9a200c5c2 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1805445 @@ -0,0 +1,19 @@ + +QEMU arm virt machine was stopped by STMFD command while debug process + +Hello, i have a big problem with QEMU arm virtual machine. So... +I run QEMU machine with bare-metal ThreadX fullflash from Texet TM-333 phone (Spreadtrum platform) +[CODE]qemu-system-arm -S -gdb tcp::1234,ipv4 -drive file=C:\cygwin64\home\flash.bin,if=mtd,format=raw -M palmetto-bmc -cpu arm926 -m 64M[/CODE] +I use palmetto-bmc platform because it have ARM926EJ-S core and support SPI Flash. +Then, i attach to gdb qemu process from IDA and run code step-by-step. +[IMG]https://pp.userapi.com/c847218/v847218546/13ec1c/iSIcre5-js4.jpg[/IMG] + +When the IDA run 00032534 STR R11, [R10] command +[IMG]https://pp.userapi.com/c846416/v846416708/133f60/GQzxORvf4Tg.jpg[/IMG] + +instead of store R11 on R10 adress, it jump 000328DC STMFD SP!, {R0-R12,LR} instruction... +[IMG]https://pp.userapi.com/c847218/v847218546/13ec26/32A0VcaJywg.jpg[/IMG] +and virt machine not execute new instruction... +[IMG]https://pp.userapi.com/c850624/v850624111/528f3/N7FTpgloWVU.jpg[/IMG] + +and why i did not change flash from n25q256a to n25q032a11 in aspeed.c without rebuild qemu? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1806243 b/results/classifier/gemma3:12b/debug/1806243 new file mode 100644 index 000000000..15392f380 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1806243 @@ -0,0 +1,85 @@ + +ARM conditional branch after if-then instruction not working + +Hello + +There seems to be an issue with QEMU when debugging if-then condition blocks from the thumb2 instruction set. The following snippet runs fine during normal execution, but keeps hanging at the conditional branch when debugging. The jump at the branch should only be executed as long as $r0 is lower than $r1. Problem is that once both are equal, the execution is not continued past the branch and the program counter never gets popped. + +2000407a: push {lr} +2000407c: movs r0, r6 +2000407e: ldmia r7!, {r1, r6} +20004080: push {r0, r1} +20004082: str.w r6, [r7, #-4]! +20004086: ldr r6, [sp, #0] +20004088: pop {r0, r1} +2000408a: adds r0, #1 +2000408c: cmp r0, r1 +2000408e: itt lt +20004090: pushlt {r0, r1} +20004092: blt.w 0x20004082 ; unpredictable <IT:lt> // <-- GDB hangs here +20004096: pop {pc} + +I have tried to reproduce the problem with inline assembly but for some reason the following example just worked: + +void f() { + static uint8_t stack[256]{}; + stack[255] = 4; + + asm volatile("\n\t" + "push {lr}" + "\n\t" + + // pre-conditions + "movs r7, %[stack]" + "\n\t" + "movs r6, #1" + "\n\t" + + "movs r0, r6" + "\n\t" + "ldmia r7!, {r1, r6}" + "\n\t" + "push {r0, r1}" + "\n\t" + "1:" + "\n\t" + "str.w r6, [r7, #-4]!" + "\n\t" + "ldr r6, [sp, #0]" + "\n\t" + "pop {r0, r1}" + "\n\t" + "adds r0, #1" + "\n\t" + "cmp r0, r1" + "\n\t" + "itt lt" + "\n\t" + "pushlt {r0, r1}" + "\n\t" + + // Original instruction + //"blt.w 0x20004082" // ; unpredictable <IT:lt> + + // Trying to fake it + "blt.w 1b" + "\n\t" + + "pop {pc}" + "\n\t" + : + : [stack] "r"(&stack[255])); +} + +The only real major difference I see to the other code snipped is that the inline assembly is running from flash memory where as the original code runs in ram? Maybe that's a clue somehow? + +Quickly reading through already reported ARM bugs I think this might be related: +https://bugs.launchpad.net/qemu/+bug/1364501 +At least the symptoms sound identical. + + +The versions I'm running are: +QEMU 3.0.0 +arm-none-eabi-gdb 8.2 + +I've also captured some trace output for single stepping from the pushlt to the blt.w instruction with the trace arguments unimp, guest_errors, op, int, exec. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1810545 b/results/classifier/gemma3:12b/debug/1810545 new file mode 100644 index 000000000..c01a4c22d --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1810545 @@ -0,0 +1,16 @@ + +[alpha] Strange exception address reported + +For some reason the SIGILL handler receives a different address under qemu than it used to on real hardware. I don't know specifics about the hardware used back then – it was some sort of 21264a somewhere between 600-800 MHz –, and I cannot say anything about the kernel as well, but I know that it delivered the faulting address +4, while under qemu it receives +8. I know because CACAO, an early Java JIT compiler extracts the address from the SIGILL handler and inspects the code at the faulting site, and it has substracted 4 from the handler address since the dawn of time, and this used to produce the desired result on the Alpha hardware. It actually ran on two different Alpha machines over the years, and both behaved identically. + +The handler looks like this: +void handler_sigill(int sig, siginfo_t *siginfo, void *_p) +{ + uintptr_t trap_address = (uintptr_t) (((ucontext_t*) _p)->uc_mcontext.sc_pc) - 4; +} + +(paraphrasing, the actual code is here: https://bitbucket.org/cacaovm/cacao-staging/src/c8d3fbab864c3243f97629fcfa8d84ba71f38157/src/vm/jit/alpha/linux/md-os.cpp?at=default&fileviewer=file-view-default#md-os.cpp-65) + +I don't know much about the qemu source code and cannot say where this is coming from at first glance. The gen_invalid function uses pc_next, which sounds like the next instruction, not the next-to-next ;). In theory it could actually be the kernel's fault, although I consider this unlikely. + +This is qemu-system-alpha with apparently the last Debian which existed for Alpha (lenny). The kernel is 2.6.26-2-alpha-generic (Debian 2.6.26-29). Observed with qemu git 1b3e80082b, but I guess it is the same with any version. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1812091 b/results/classifier/gemma3:12b/debug/1812091 new file mode 100644 index 000000000..2613a882b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1812091 @@ -0,0 +1,21 @@ + +gdbstub memory accesses performed with wrong attributes + +Qemu-commit: b2f7c27f56bf1116ebb7848c75914aa7c5d6a040 + + +The ARMv8-M architecture (with security extensions) contains a SAU, the Security Attribution Unit. After booting the mps2-an505 and immediately halting (`-S`), I attempt to read the SAU_TYPE register, located at 0xE000EDD4, using gdb (x 0xE000EDD4). The returned value is 0, while the expected value is 8 (number of regions). + +On further investigation, it seems that `attrs.secure` is set to false (armv7m_nvic.c - nvic_readl, line 1167). Commenting out the check will return the correct value. + +As the CPU should be in 'secure' mode after reset, I think this behavior is wrong. + +Steps to reproduce: +Example code that loads an endless loop into the beginning of secure memory: https://github.com/ajblane/armv8m-hello + +Commandline: qemu-system-arm -machine mps2-an505 -cpu cortex-m33 \ + -m 4096 \ + -nographic -serial mon:stdio \ + -kernel $(IMAGE) -s -S + +Attach with arm-none-eabi-gdb, and run x 0xE000EDD4. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1813010 b/results/classifier/gemma3:12b/debug/1813010 new file mode 100644 index 000000000..3ed8cf628 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1813010 @@ -0,0 +1,24 @@ + +Parallel builds fail (make -j >=2) when using --extra-cflags "--save-temps" + +specs: +Host kernel: Linux 4.19.16-1-lts +Host type: x86_64 GNU/Linux +Host distro: Archlinux +Guest: we never get that far +QEMU commit: 9f33051abce238ab43a23125e237aac8b0931b88 + + +steps: +# fresh copy of the latest commit +> git clone https://git.qemu.org/git/qemu.git + +# separate build dir +> mkdir build +> cd build + +# sample configuration for riscv (this happens for other targets as well) +> ../qemu/configure --target-list=riscv64-softmmu --enable-debug --extra-cflags='-O0 -g3 -save-temps' --prefix=/install/riscv-qemu + +# this will fail (see attached log file) +> make -j 2 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1813305 b/results/classifier/gemma3:12b/debug/1813305 new file mode 100644 index 000000000..8a3d845aa --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1813305 @@ -0,0 +1,18 @@ + +trace-root.h is not regerenerated after re-configure + +Hi, + +I've just realized that after I reconfigured my qemu with +../configure --target-list=arm-softmmu,arm-linux-user,aarch64-softmmu,aarch64-linux-user --enable-trace-backends=simple + +$ make +did rebuild some stuff for the 'simple' trace, but it did not update trace-root.h until after I +$ make clean + + +I took me while to understand why I didn't get the traces I wanted (my trace-root.h still thought it was configured for the default 'log'). + +I didn't check how easy it is to fix this in the build system. + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1815911 b/results/classifier/gemma3:12b/debug/1815911 new file mode 100644 index 000000000..a6f02a0ba --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1815911 @@ -0,0 +1,20 @@ + +aptitude crashes qemu-m68k with handle_cpu_signal received signal outside vCPU context + +When building a package with sbuild on Debian, sbuild can use aptitude to resolve dependencies. + +Recently, some changes introduced to aptitude or related packages cause qemu to crash: + +(sid-m68k-sbuild)root@nofan:/# aptitude -y --without-recommends -o Dpkg::Options::=--force-confold -o Aptitude::CmdLine::Ignore-Trust-Violations=false -o Aptitude::ProblemResolver::StepScore=100 -o Aptitude::ProblemResolver::SolutionCost="safety, priority, non-default-versions" -o Aptitude::ProblemResolver::Hints::KeepDummy="reject sbuild-build-depends-core-dummy :UNINST" -o Aptitude::ProblemResolver::Keep-All-Level=55000 -o Aptitude::ProblemResolver::Remove-Essential-Level=maximum install vim +Warning: Invalid locale (please review locale settings, this might lead to problems later): + locale::facet::_S_create_c_locale name not valid +The following NEW packages will be installed: + libgpm2{a} vim vim-common{a} vim-runtime{a} xxd{a} +0 packages upgraded, 5 newly installed, 0 to remove and 1 not upgraded. +Need to get 7225 kB/7260 kB of archives. After unpacking 33.5 MB will be used. +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6019d1bf +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x601b64ab +Segmentation fault +(sid-m68k-sbuild)root@nofan:/# + +The crash does not reproduce on real hardware running Debian unstable. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1826568 b/results/classifier/gemma3:12b/debug/1826568 new file mode 100644 index 000000000..29c23b1b9 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1826568 @@ -0,0 +1,14 @@ + +RISC-V Disassembler/translator instruction decoding disagreement + + +When running QEMU V3.1.0 for platform RISC-V, 64bit, Spike V1.10 with "-d in_asm -singlestep -D qemu_log.txt", my (faulty) test code brought up this message in the logs: + + 0x000000008002cade: 051300009517e2bf illegal + Disassembler disagrees with translator over instruction decoding + Please report this to <email address hidden> + + +You may want to resolve the disagreement. + +Axel \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1827 b/results/classifier/gemma3:12b/debug/1827 new file mode 100644 index 000000000..649b4cac4 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1827 @@ -0,0 +1,2 @@ + +Turn DPRINTF macro use into tracepoints diff --git a/results/classifier/gemma3:12b/debug/1828723 b/results/classifier/gemma3:12b/debug/1828723 new file mode 100644 index 000000000..ca90501c8 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1828723 @@ -0,0 +1,6 @@ + +[RFE] option to suppress gemu_log() output + +With user mode emulation, messages from genu_log() are emitted unconditionally to stderr. I didn't find a way to suppress them. It would be nice to have options similar to the -D/-d options to be able to filter and/or redirect the output. + +My use case is chroot/container execution for different architectures via binfmt. In this case it will appear as if the binary in question had emitted messages like "Unsupported setsockopt ..." to stderr while in fact the message came from qemu-*-static. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1834496 b/results/classifier/gemma3:12b/debug/1834496 new file mode 100644 index 000000000..77859a1c0 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1834496 @@ -0,0 +1,28 @@ + +Regressions on arm target with some GCC tests + +Hi, + +After trying qemu master: +commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde +Merge: 68d7ff0 14f5d87 +Author: Peter Maydell <email address hidden> +Date: Fri Jun 21 15:40:50 2019 +0100 + +I found several regressions compared to qemu-3.1 when running the GCC testsuite. +I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests. + +All tests used to pass w/o error (one of them is verbose), but with a recent qemu, all of them make qemu crash: + +qemu: uncaught target signal 6 (Aborted) - core dumped + +This was noticed with GCC master configured with +--target arm-none-linux-gnueabi +--with-mode arm +--with-cpu cortex-a9 + +and calling qemu with --cpu cortex-a9 (the script uses "any", this makes no difference). + +I have noticed other failures with arm-v8 code, but this is probably the same root cause. Since it's a bit tedious to manually rebuild & extract the testcases, I'd prefer to start with this subset, and I can extract more if needed later. + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1835466 b/results/classifier/gemma3:12b/debug/1835466 new file mode 100644 index 000000000..1ea01a200 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1835466 @@ -0,0 +1,131 @@ + +qemu 4.0.0 abort()s in audio_get_pdo_in (poisoned drv->driver?) + +After upgrading qemu from 3.0.0 to 4.0.0 (compiled from release tarball), I'm seeing a (reproducible) crash related to audio subsystem. + +I recompiled qemu with debugging options and got it to crash under gdb: + +Thread 6 "qemu-system-x86" received signal SIGABRT, Aborted. +0x00007ffff52e420b in raise () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff52e420b in raise () at /lib64/libc.so.6 +#1 0x00007ffff52c6524 in abort () at /lib64/libc.so.6 +#2 0x000000000041ec33 in audio_get_pdo_in (dev=<optimized out>) at audio/audio_template.h:328 +#3 0x00000000005d0123 in AUD_open_in + (card=0x7ffdde98dbc8, sw=0x7ffff17444e0, name=0x999d80 "adc", callback_opaque=callback_opaque@entry=0x7ffdde98fd58, callback_fn=0x610940 <hda_audio_input_cb>, as=as@entry=0x7ffdde98fd84) at audio/audio_template.h:434 +#4 0x000000000060fe2e in hda_audio_setup (st=0x7ffdde98fd58) at hw/audio/hda-codec.c:490 +#5 0x000000000061051b in hda_audio_command (hda=0x7ffdde98db40, nid=4, data=<optimized out>) at hw/audio/hda-codec.c:590 +#6 0x000000000060ea20 in intel_hda_send_command (d=d@entry=0x7ffff0a2fc00, verb=verb@entry=4341777) at hw/audio/intel-hda.c:301 +#7 0x000000000060ebbe in intel_hda_corb_run (d=<optimized out>) at hw/audio/intel-hda.c:336 +#8 0x000000000060ebbe in intel_hda_corb_run (d=0x7ffff0a2fc00) at hw/audio/intel-hda.c:305 +#9 0x0000000000495b99 in memory_region_write_accessor + (mr=mr@entry=0x7ffff0a307a0, addr=72, value=value@entry=0x7fffeddfe568, size=size@entry=2, shift=<optimized out>, mask=mask@entry=65535, attrs=...) + at memory.c:502 +#10 0x000000000049448e in access_with_adjusted_size + (addr=addr@entry=72, value=value@entry=0x7fffeddfe568, size=size@entry=2, access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=access_fn@entry=0x495b10 <memory_region_write_accessor>, mr=0x7ffff0a307a0, attrs=...) at memory.c:568 +#11 0x00000000004974f3 in memory_region_dispatch_write (mr=mr@entry=0x7ffff0a307a0, addr=72, data=<optimized out>, size=2, attrs=attrs@entry=...) + at memory.c:1496 +#12 0x000000000042afbc in flatview_write_continue + (fv=fv@entry=0x7ffdd36ef5c0, addr=addr@entry=4228186184, attrs=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=len@entry=2, addr1=<optimized out>, l=<optimized out>, mr=0x7ffff0a307a0) at exec.c:3279 +#13 0x000000000042b1d6 in flatview_write + (fv=0x7ffdd36ef5c0, addr=addr@entry=4228186184, attrs=attrs@entry=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=len@entry=2) + at exec.c:3318 +#14 0x000000000042e2a6 in address_space_write + (as=0xfc5080 <address_space_memory>, addr=4228186184, attrs=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=2) + at exec.c:3408 +#15 0x000000000042e33a in address_space_rw (as=<optimized out>, addr=<optimized out>, attrs=..., + attrs@entry=..., buf=buf@entry=0x7ffff66c7028 <incomplete sequence \311>, len=<optimized out>, is_write=<optimized out>) at exec.c:3419 +#16 0x00000000004ac3c6 in kvm_cpu_exec (cpu=cpu@entry=0x7ffff0a81140) at accel/kvm/kvm-all.c:2034 +#17 0x00000000004812ae in qemu_kvm_cpu_thread_fn (arg=0x7ffff0a81140) at cpus.c:1281 +#18 0x00000000004812ae in qemu_kvm_cpu_thread_fn (arg=arg@entry=0x7ffff0a81140) at cpus.c:1254 +#19 0x000000000089d0eb in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:502 +#20 0x00007ffff549319c in start_thread () at /lib64/libpthread.so.0 +#21 0x00007ffff53ba4af in clone () at /lib64/libc.so.6 + + +After some poking around, I think there's something overwriting dev->driver so this switch(dev->driver) statement falls through to abort(): https://git.qemu.org/?p=qemu.git;a=blob;f=audio/audio_template.h;h=1232bb54db0e7073e60e3ccb72c1ed72cf5e3831;hb=131b9a05705636086699df15d4a6d328bb2585e8#l304 + + +Here's why I think so: + +$ export QEMU_AUDIO_DRV=pa +$ gdb /usr/bin/qemu-system-x86_64 +(gdb) b qpa_audio_init +Breakpoint 1 at 0x79bcb0: file audio/paaudio.c, line 831. +(gdb) b audio_get_pdo_in +Breakpoint 2 at 0x5ce320: file audio/audio_template.h, line 304. +(gdb) run -enable-kvm -cpu Nehalem -machine q35 -device intel-iommu -name Workstation -smp 4 -m 8G -soundhw hda -rtc base=localtime -drive file=workstation-disk0.qcow2,if=virtio,format=qcow2 -drive file=workstation-disk1.qcow2,if=virtio,format=qcow2 -net nic,model=virtio,macaddr=aa:bb:cc:dd:ee:ff -net tap,ifname=tap42 -monitor telnet:127.0.0.1:7043,server,nowait -pidfile workstation.pid -vga qxl -global qxl-vga.vgamem_mb=64 -device usb-ehci,id=ehci -device usb-host,vendorid=0x1390,productid=0x5454,bus=ehci.0 -device usb-host,vendorid=0x054c,bus=ehci.0 -device usb-tablet -device nec-usb-xhci,id=xhci -device usb-host,vendorid=0x10c4,productid=0x888e,bus=xhci.0 + +Thread 1 "qemu-system-x86" hit Breakpoint 1, qpa_audio_init (dev=0x7ffff161b6a0) at audio/paaudio.c:831 +(gdb) p (*dev)->driver +$1 = AUDIODEV_DRIVER_PA +(gdb) p/d AUDIODEV_DRIVER_PA +$2 = 5 +(gdb) cont +Continuing. +[Thread 0x7ffff09ff700 (LWP 4078) exited] +audio: warning: Using timer based audio emulation +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304 +(gdb) p (*dev)->driver +$3 = AUDIODEV_DRIVER_PA +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304 +(gdb) p (*dev)->driver +$4 = AUDIODEV_DRIVER_PA +(gdb) cont +Continuing. + +Thread 1 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304 +(gdb) p (*dev)->driver +$5 = AUDIODEV_DRIVER_PA +(gdb) cont +Continuing. +[New Thread 0x7ffff09ff700 (LWP 4483)] +[New Thread 0x7ffddcdff700 (LWP 4489)] +[New Thread 0x7ffddbdff700 (LWP 4490)] +[New Thread 0x7ffddb1ff700 (LWP 4491)] +[New Thread 0x7ffdd2dff700 (LWP 4494)] +[New Thread 0x7ffdd25fe700 (LWP 4495)] +[New Thread 0x7ffdd1dfd700 (LWP 4497)] +[New Thread 0x7ffdda5ff700 (LWP 4500)] +[New Thread 0x7ffdcedff700 (LWP 4501)] +qemu-system-x86_64: warning: guest updated active QH +[Switching to Thread 0x7fffef7ff700 (LWP 4097)] + +Thread 4 "qemu-system-x86" hit Breakpoint 2, audio_get_pdo_in (dev=0x7ffff161b6a0) at audio/audio_template.h:304 +(gdb) p (*dev)->driver +$6 = 176 + + +For what it's worth, guest is Fedora 29, host is a Slackware system with qemu compiled (manually) with these options: + +CFLAGS="-O2 -fPIC" \ +CXXFLAGS="-O2 -fPIC" \ +./configure \ + --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc --localstatedir=/var \ + --enable-gtk \ + --enable-system \ + --enable-kvm \ + --enable-virtfs \ + --enable-sdl \ + --enable-gnutls \ + --enable-curses \ + --enable-virtfs \ + --enable-curl \ + --enable-linux-aio \ + --enable-vhost-net \ + --enable-spice \ + --enable-libusb \ + --enable-usb-redir \ + --enable-lzo \ + --enable-bzip2 \ + --enable-libssh2 \ + --enable-numa \ + --enable-jemalloc \ + --enable-opengl \ + --audio-drv-list=alsa,oss,sdl,pa \ + --enable-vnc --enable-vnc-sasl --enable-vnc-png --enable-vnc-jpeg \ + --target-list=i386-softmmu,x86_64-softmmu,i386-linux-user,x86_64-linux-user,arm-softmmu,arm-linux-user,armeb-linux-user,sparc64-softmmu,sparc-softmmu,sparc32plus-linux-user,sparc64-linux-user \ + --enable-debug --extra-cflags="-g3" --extra-ldflags="-g3" --disable-strip --disable-pie # For debugging only \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1838277 b/results/classifier/gemma3:12b/debug/1838277 new file mode 100644 index 000000000..1b981724a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1838277 @@ -0,0 +1,22 @@ + +qemu-system-aarch64: regression in 3.1: breakpoint instructions always routed to EL_D even when current EL is higher + +Affects 3.1.0 (latest stable release) and latest commit (893dc8300c80e3dc32f31e968cf7aa0904da50c3) but did *not* affect 2.11 (qemu from bionic ubuntu LTS). + +With the following code and shell commands: + +test.s: + +.text +mov x0, #0x60000000 +msr vbar_el2, x0 +dsb sy +isb sy + +$ aarch64-none-elf-as test.s -o test.o +$ aarch64-none-elf-objcopy -S -O binary test.o test.bin +$ qemu-system-aarch64 -nographic -machine virt,virtualization=on -cpu cortex-a57 -kernel test.bin -s -S + +vbar_el2 is still 0 after the code, instead of being the expected 0x60000000. (see screenshot). + +This regression doesn't seem to happen for vbar_el1 & virtualization=off. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1838475 b/results/classifier/gemma3:12b/debug/1838475 new file mode 100644 index 000000000..32132f131 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1838475 @@ -0,0 +1,19 @@ + +qemu-system-arm exits when cortex-m4 floating point used and irq occurs + +qemu-system-arm exits with + +"...Secure UsageFault with CFSR.NOCP because NSACR.CP10 prevents stacking FP regs +...taking pending nonsecure exception 3 +Taking exception 7 [Breakpoint] +qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)" + +when emulating Cortex-m4, executing at least 1 floating point instruction, and then an irq (e.g. sys tick) occurring. + +CPACR.CP10 and CPACR.CP11 are set to 0x3 respectively prior to executing the fp instructions. + +NOTE: NSACR does not appear to be a cortex m4 register. + +Attached is a simplified elf to repro the issue. + +The qemu command line is: "qemu-system-arm --gdb tcp::1234 -cpu cortex-m4 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel QemuExitWhenUsingFPAndIRQOccurs.elf -d int" \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1840922 b/results/classifier/gemma3:12b/debug/1840922 new file mode 100644 index 000000000..c3962208b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1840922 @@ -0,0 +1,22 @@ + +qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8 + +Hi, + +While experimenting with running the GCC testsuite with cortex-m33 as target (to exercise v8-m code), I came across this failure: +qemu: unhandled CPU exception 0x8 - aborting +R00=fffeaf58 R01=fffeaf58 R02=00000000 R03=fffeaf5d +R04=fffeaf5c R05=fffeaf9c R06=00000000 R07=fffeaf80 +R08=00000000 R09=00000000 R10=00019dbc R11=00000000 +R12=000000f0 R13=fffeaf58 R14=000081f3 R15=fffeaf5c +XPSR=61000000 -ZC- T NS priv-thread +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6033c908 + +I'm using arm-eabi-gcc, so it targets bare-metal, not linux. + +The testcase is GCC's gcc/testsuite/gcc.c-torture/execute/20000822-1.c; it works when compiled at -O2, but crashes when compiled at -Os. The test uses nested functions, so it creates a trampoline on the stack, whose address may be a problem. But since the stack address seems to be in the same range in the O2 and Os cases, it's not that clear. + +I'm attaching the C source, asm, binary executables and qemu traces with in_asm,cpu. + +I execute the binaries with: +qemu-arm --cpu cortex-m33 ./20000822-1.exe.Os \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1843133 b/results/classifier/gemma3:12b/debug/1843133 new file mode 100644 index 000000000..b51198e15 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1843133 @@ -0,0 +1,77 @@ + +Possibly incorrect branch in qemu-system-hppa + +I plan to release a new GNU Lightning soon. +I no longer have access to any physical HPPA, but code that +was tested some years ago did work on HPPA/HP-UX, and now it +appears qemu-system-hppa incorrectly branches in code generated +by GNU Lightning. Currently only 32 bit hppa jit generation +supported. + +In the lightning check/test tool, the code would be: + +.code + prolog + movi %r0 0x7fffffff + movi %r1 1 + boaddr L0 %r0 %r1 + calli @abort +L0: + ret + epilog + +The code/debug information looks like this: + movi r4 0x7fffffff + 0xf8ef5018 ldil L%7ffff800,r4 + 0xf8ef501c ldo 7ff(r4),r4 + movi r5 0x1 + 0xf8ef5020 ldi 1,r5 + boaddr L1 r4 r5 + 0xf8ef5024 addb,sv,n r5,r4,0xf8ef5044 :a.tst:291 + 0xf8ef5028 nop + calli 0xf8eeb68a + [...] + L1: + +Apparently it is not understanding 0x7fffffff + 1 is a signed overflow. + +Tested in Fedora with qemu-system-hppa-3.1.1-2.fc30.x86_64 and using +the debian-10 image. + +To make it a bit easier to test (partially transformed the +not so optimized code generated by lightning to gcc -S output): +# cat a.s + .LEVEL 1.1 + .text + .align 4 +.globl main + .type main, @function +main: + .PROC + .CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3 + .ENTRY + copy %r3,%r1 + copy %r30,%r3 + stwm %r1,64(%r30) + zdepi -1,31,31,%r23 + ldi 1,%r24 + addb,sv,n %r24,%r23,.L0 + nop + ldi 1,%r28 + b,n .L1 + nop +.L0: + ldi 0,%r28 +.L1: + ldo 64(%r3),%r30 + ldwm -64(%r30),%r3 + bv,n %r0(%r2) + .EXIT + .PROCEND + .size main, .-main + +# gcc a.s +# ./a.out; echo $? +1 + +It should have returned 0. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1844814 b/results/classifier/gemma3:12b/debug/1844814 new file mode 100644 index 000000000..21ebd13d2 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1844814 @@ -0,0 +1,26 @@ + +trace: SystemTap documentation out of date + +The docs/devel/tracing.txt help suggest: + + scripts/tracetool.py --backends=dtrace --format=stap \ + --binary path/to/qemu-binary \ + --target-type system \ + --target-name x86_64 \ + <trace-events-all >qemu.stp + +but since commit 2098c56a9bc this comment is outdated: + + $ scripts/tracetool.py --backends=dtrace --format=stap \ + --binary mips-softmmu/qemu-system-mips \ + --target-type system \ + --target-name mips trace-events-all + Error: group name is required + +The offending commit seems: + +commit 2098c56a9bc5901e145fa5d4759f075808811685 +Author: Daniel P. Berrange <email address hidden> +Date: Wed Jan 25 16:14:14 2017 +0000 + + trace: move setting of group name into Makefiles \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1844817 b/results/classifier/gemma3:12b/debug/1844817 new file mode 100644 index 000000000..567d56ecd --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1844817 @@ -0,0 +1,25 @@ + +trace: dynamic width format syntax not validated + +The dtrace via stap backend cannot support the dynamic '*' width format. + +Eric noted in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg04720.html: + + https://sourceware.org/systemtap/langref.pdf + + section 9.2 printf, states: + + "The printf formatting directives are similar to those of C, except that + they are fully checked for type by the translator." + + and does NOT list handling for '*' under precision or width. + +Some trace events have been merged without checking this: + +$ git ls-files|fgrep trace-event|xargs git grep '*\("\|x\)' +hw/block/trace-events:11:pflash_io_read(uint64_t offset, int width, int fmt_width, uint32_t value, uint8_t cmd, uint8_t wcycle) "offset:0x%04"PRIx64" width:%d value:0x%0*x cmd:0x%02x wcycle:%u" +hw/block/trace-events:12:pflash_io_write(uint64_t offset, int width, int fmt_width, uint32_t value, uint8_t wcycle) "offset:0x%04"PRIx64" width:%d value:0x%0*x wcycle:%u" +hw/block/trace-events:13:pflash_data_read(uint64_t offset, int width, uint32_t value) "data offset:0x%04"PRIx64" value:0x%0*x" +hw/block/trace-events:14:pflash_data_write(uint64_t offset, int width, uint32_t value, uint64_t counter) "data offset:0x%04"PRIx64" value:0x%0*x counter:0x%016"PRIx64 +hw/mips/trace-events:2:gt64120_read(const char *regname, int width, uint64_t value) "gt64120 read %s value:0x%0*" PRIx64 +hw/mips/trace-events:3:gt64120_write(const char *regname, int width, uint64_t value) "gt64120 write %s value:0x%0*" PRIx64 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1848 b/results/classifier/gemma3:12b/debug/1848 new file mode 100644 index 000000000..e8c4b2cfb --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1848 @@ -0,0 +1,26 @@ + +8.1.0 build failure ../accel/tcg/cputlb.c: In function ‘do_ld_mmio_beN’: error: call to ‘qemu_build_not_reached_always’ declared with attribute error: code path is reachable +Description of problem: +Error when building with -Og. Does not occur with -O2. + +``` +FAILED: libqemu-i386-softmmu.fa.p/accel_tcg_cputlb.c.o +x86_64-pc-linux-gnu-gcc -m64 -mcx16 -Ilibqemu-i386-softmmu.fa.p -I. -I.. -Itarget/i386 -I../target/i386 -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/opus -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -isystem /x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/linux-headers -isystem linux-headers -iquote . -iquote /x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0 -iquote /x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/include -iquote /x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/host/include/x86_64 -iquote /x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/host/include/generic -iquote /x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/tcg/i386 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -march=amdfam10 -Og -g -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="i386-softmmu-config-target.h"' '-DCONFIG_DEVICES="i386-softmmu-config-devices.h"' -MD -MQ libqemu-i386-softmmu.fa.p/accel_tcg_cputlb.c.o -MF libqemu-i386-softmmu.fa.p/accel_tcg_cputlb.c.o.d -o libqemu-i386-softmmu.fa.p/accel_tcg_cputlb.c.o -c ../accel/tcg/cputlb.c +In file included from ../accel/tcg/cputlb.c:20: +../accel/tcg/cputlb.c: In function ‘do_ld_mmio_beN’: +/x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/include/qemu/osdep.h:244:35: error: call to ‘qemu_build_not_reached_always’ declared with attribute error: code path is reachable + 244 | #define qemu_build_not_reached() qemu_build_not_reached_always() + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../accel/tcg/cputlb.c:2121:13: note: in expansion of macro ‘qemu_build_not_reached’ + 2121 | qemu_build_not_reached(); + | ^~~~~~~~~~~~~~~~~~~~~~ +../accel/tcg/cputlb.c: In function ‘do_st_mmio_leN’: +/x/portage/app-emulation/qemu-8.1.0/work/qemu-8.1.0/include/qemu/osdep.h:244:35: error: call to ‘qemu_build_not_reached_always’ declared with attribute error: code path is reachable + 244 | #define qemu_build_not_reached() qemu_build_not_reached_always() + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +../accel/tcg/cputlb.c:2764:13: note: in expansion of macro ‘qemu_build_not_reached’ + 2764 | qemu_build_not_reached(); + | ^~~~~~~~~~~~~~~~~~~~~~ +``` + +Downstream bug: https://bugs.gentoo.org/913083 diff --git a/results/classifier/gemma3:12b/debug/1852 b/results/classifier/gemma3:12b/debug/1852 new file mode 100644 index 000000000..bfadb48e5 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1852 @@ -0,0 +1,111 @@ + +aarch64: crash failed to analyze vmcore of dump-guest-memory +Description of problem: +``` +1、 dump guest memory +virsh qemu-monitor-command 3 --hmp "dump-guest-memory /home/ecs3.kdump" +2、crash kdump failed +[root@ceasphere-node-1 home]# ./crash ./vmlinux ./ecs3.kdump + +crash 7.2.9-2.el8 +Copyright (C) 2002-2020 Red Hat, Inc. +Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation +Copyright (C) 1999-2006 Hewlett-Packard Co +Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited +Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. +Copyright (C) 2005, 2011 NEC Corporation +Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. +Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. +This program is free software, covered by the GNU General Public License, +and you are welcome to change it and/or distribute copies of it under +certain conditions. Enter "help copying" to see the conditions. +This program has absolutely no warranty. Enter "help warranty" for details. + +crash: read error: kernel virtual address: ffff000010e0ba48 type: "vabits_user" +GNU gdb (GDB) 7.6 +Copyright (C) 2013 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "aarch64-unknown-linux-gnu"... + +crash: read error: kernel virtual address: ffff000011a609b8 type: "possible" +WARNING: cannot read cpu_possible_map +crash: read error: kernel virtual address: ffff000011a60bb8 type: "present" +WARNING: cannot read cpu_present_map +crash: read error: kernel virtual address: ffff000011a607b8 type: "online" +WARNING: cannot read cpu_online_map +crash: read error: kernel virtual address: ffff000011a60db8 type: "active" +WARNING: cannot read cpu_active_map +crash: read error: kernel virtual address: ffff0000123da120 type: "shadow_timekeeper xtime_sec" +crash: read error: kernel virtual address: ffff000011a6a6ac type: "init_uts_ns" +crash: ./vmlinux and ./ecs3.kdump do not match! + +Usage: + + crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form) + crash [OPTION]... [NAMELIST] (live system form) + +Enter "crash -h" for details. +``` +Steps to reproduce: +1. virsh create vm.xml +2. virsh qemu-monitor-command 3 --hmp "dump-guest-memory /home/ecs3.kdump" +3. crash ./vmlinux ./ecs3.kdump +Additional information: +The vmcore by 'echo c > /proc/sysrq-trigger' in guest is ok, crash work. + +``` +[root@ceasphere-node-1 home]# crash ./vmlinux ./vmcore + +crash 8.0.3-1.el9 +Copyright (C) 2002-2022 Red Hat, Inc. +Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation +Copyright (C) 1999-2006 Hewlett-Packard Co +Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited +Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. +Copyright (C) 2005, 2011, 2020-2022 NEC Corporation +Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. +Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. +Copyright (C) 2015, 2021 VMware, Inc. +This program is free software, covered by the GNU General Public License, +and you are welcome to change it and/or distribute copies of it under +certain conditions. Enter "help copying" to see the conditions. +This program has absolutely no warranty. Enter "help warranty" for details. + +GNU gdb (GDB) 10.2 +Copyright (C) 2021 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "aarch64-unknown-linux-gnu". +Type "show configuration" for configuration details. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... + + KERNEL: ./vmlinux + DUMPFILE: ./vmcore [PARTIAL DUMP] + CPUS: 4 + DATE: Wed Aug 30 09:06:01 CST 2023 + UPTIME: 00:01:08 +LOAD AVERAGE: 0.91, 0.34, 0.12 + TASKS: 158 + NODENAME: localhost + RELEASE: 4.18.0-305.3.1.el8.aarch64 + VERSION: #1 SMP Tue Jun 1 16:22:50 UTC 2021 + MACHINE: aarch64 (unknown Mhz) + MEMORY: 16 GB + PANIC: "sysrq: SysRq : Trigger a crash" + PID: 1310 + COMMAND: "bash" + TASK: ffff8003d47d3200 [THREAD_INFO: ffff8003d47d3200] + CPU: 1 + STATE: TASK_RUNNING (SYSRQ) + +crash> +``` diff --git a/results/classifier/gemma3:12b/debug/1854738 b/results/classifier/gemma3:12b/debug/1854738 new file mode 100644 index 000000000..69735337d --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1854738 @@ -0,0 +1,29 @@ + +ppc doesn't support for mttcg but ppc64 supported + +Currently ppc and ppc64abi32 doesn't suppport for mttcg, I am looking for support +``` + ppc) + gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml power-spe.xml" + ;; + ppc64) + TARGET_BASE_ARCH=ppc + TARGET_ABI_DIR=ppc + mttcg=yes + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" + ;; + ppc64le) + TARGET_ARCH=ppc64 + TARGET_BASE_ARCH=ppc + TARGET_ABI_DIR=ppc + mttcg=yes + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" + ;; + ppc64abi32) + TARGET_ARCH=ppc64 + TARGET_BASE_ARCH=ppc + TARGET_ABI_DIR=ppc + echo "TARGET_ABI32=y" >> $config_target_mak + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" + ;; +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1856 b/results/classifier/gemma3:12b/debug/1856 new file mode 100644 index 000000000..abe68a337 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1856 @@ -0,0 +1,14 @@ + +Replay got stuck with consecutive hardware interrupts coming +Description of problem: +I recorded bin file using **_rr=record_** command line. But it got stuck when replaying this record bin file. The icount number would never change after stucking if I typed _**info replay**_ with qmp command line. + +I found that the following instructions should be a sequence of consecutive hardware interrupts after stucking once checking the trace log of +both replay and record log using _**-d in_asm,int**_. +Steps to reproduce: +1.pulling from remote which the newest commit ID is 156618d9ea67f2f2e31d9dedd97f2dcccbe6808c +2.emulating Windows 7 OS on aarch64 Host with TCG acceleration mechanism +3.using **_rr=record_** to make replay file and tracing guest code and interrupts using _**-d in_asm,int**_ +4.replaying the previous file and also tracing guest code and interrupts +Additional information: +# diff --git a/results/classifier/gemma3:12b/debug/1856837 b/results/classifier/gemma3:12b/debug/1856837 new file mode 100644 index 000000000..f482afe7d --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1856837 @@ -0,0 +1,41 @@ + +qemu 4.2.0 arm segmentation fault with gcc 9.2 + +As discussed with f4bug yesterday on IRC here comes the bug description. + +I'm building/configured qemu-4.2.0 on an x86_64 (gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516) with target-list "arm-softmmu,arm-linux-user" and debug enabled. I use the arm-linux-user variant, "qemu-arm". + +Then i'm trying to cross-compile (arm gcc) an old version of googles v8 (as i need this version of the lib for binary compatibility) which uses qemu during build. + +It worked with gcc 5.4.0 but not with 9.2.0. I also tried with 6.5.0, 7.4.0 and 8.3.0 but those are also causing the same segmentation fault. + +The executed command wich breaks qemu is: + + qemu-arm /tmp/build/out/arm.release/mksnapshot.arm --log-snapshot-positions --logfile /tmp/build/out/arm.release/obj.host/v8_snapshot/geni/snapshot.log --random-seed 314159265 /tmp/build/out/arm.release/obj.host/v8_snap + +The printed error message is: + +ARMv7=1 VFP3=1 VFP32DREGS=1 NEON=0 SUDIV=0 UNALIGNED_ACCESSES=1 MOVW_MOVT_IMMEDIATE_LOADS=0 USE_EABI_HARDFLOAT=1 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Calling qemu with gdb gives the following information: + + Thread 1 "qemu-arm" received signal SIGSEGV, Segmentation fault. + 0x0000555555d63d11 in static_code_gen_buffer () + +and + + (gdb) bt + #0 0x0000555555d63d11 in static_code_gen_buffer () + #1 0x0000555555628d58 in cpu_tb_exec (itb=<optimized out>, cpu=0x555557c33930) at + /tmp/build/qemu/accel/tcg/cpu-exec.c:172 + #2 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, + cpu=0x555557c33930) at /tmp/build/qemu/accel/tcg/cpu-exec.c:618 + #3 cpu_exec (cpu=cpu@entry=0x555557c2b660) at /tmp/build/qemu/accel/tcg/cpu-exec.c:731 + #4 0x0000555555661578 in cpu_loop (env=0x555557c33930) at /tmp/build/qemu/linux-user/arm/cpu_loop.c:219 +#5 0x00005555555d6d76 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /tmp/build/qemu/linux-user/main.c:865 + +Calling qemu-arm with debug switch "-d in_asm,int,op_opt" shows the log in the attached file. + +Thanks for any hints! +Fabian \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1857640 b/results/classifier/gemma3:12b/debug/1857640 new file mode 100644 index 000000000..4829cd729 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1857640 @@ -0,0 +1,132 @@ + +qemu-system-i386 registers clobbered after gdb set due to k_gs_base bug in gdbstub + +Due to a bug in /target/i386/gdbstub.c, setting registers in gdb causes the ones following k_gs_base to get clobbered. + +I'm using qemu version 4.2.50 on an msys64 and start qemu's i386 with a gdb server. + +$ qemu-system-i386 -version +QEMU emulator version 4.2.50 (v4.2.0-363-gdd5b0f9549-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +$ qemu-system-i386 -gdb tcp::29096 -S +C:\msys64\usr\local\qemu-system-i386.exe: invalid accelerator kvm +C:\msys64\usr\local\qemu-system-i386.exe: falling back to tcg + + +I start a gdb client, connect to the server, display the register state, set k_gs_base, display the register state again, and notice an issue. (Setting other registers also clobbers the ones after k_gs_base). + +$ gdb -q +(gdb) target remote :29096 +... +(gdb) info regs +... +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x60000010 [ CD NW ET ] +cr2 0x0 0 +... +(gdb) set $k_gs_base = 0x41414141 +(gdb) info regs +... +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x41414151 [ CD WP ET PE ] +cr2 0x60000010 1610612752 +... + + +In the gdbstub code, I notice that the read and write functions are not symmetric for IDX_SEG_REGS + 8, which corresponds to k_gs_base. + +$ cat /usr/local/src/qemu-4.2.0/target/i386/gdbstub.c +... +int x86_cpu_gdb_read_register(CPUState *cs, uint8_t *mem_buf, int n) +{ +... + case IDX_SEG_REGS + 8: +#ifdef TARGET_X86_64 + if ((env->hflags & HF_CS64_MASK) || GDB_FORCE_64) { + return gdb_get_reg64(mem_buf, env->kernelgsbase); + } + return gdb_get_reg32(mem_buf, env->kernelgsbase); +#else + return gdb_get_reg32(mem_buf, 0); +#endif +... +} +... +int x86_cpu_gdb_write_register(CPUState *cs, uint8_t *mem_buf, int n) +{ +... +#ifdef TARGET_X86_64 + case IDX_SEG_REGS + 8: + if (env->hflags & HF_CS64_MASK) { + env->kernelgsbase = ldq_p(mem_buf); + return 8; + } + env->kernelgsbase = ldl_p(mem_buf); + return 4; +#endif +... +} +... + + +I change the write function, rebuild, and verify that the issue is resolved. + +$ cat /usr/local/src/qemu-4.2.0/target/i386/gdbstub.c +int x86_cpu_gdb_write_register(CPUState *cs, uint8_t *mem_buf, int n) +{ +... + case IDX_SEG_REGS + 8: +#ifdef TARGET_X86_64 + if (env->hflags & HF_CS64_MASK) { + env->kernelgsbase = ldq_p(mem_buf); + return 8; + } + env->kernelgsbase = ldl_p(mem_buf); + return 4; +#else + return 4; +#endif +... +} +... + +$ make +... +$ make install +... + +$ qemu-system-i386 -gdb tcp::29096 -S + +$ gdb -q +(gdb) target remote :29096 +... +(gdb) info regs +... +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x60000010 [ CD NW ET ] +cr2 0x0 0 +... +(gdb) set $k_gs_base = 0x41414141 +(gdb) info regs +... +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x60000010 [ CD NW ET ] +cr2 0x0 0 +... + + +I'll submit the patch below. + +$ diff gdbstub.c gdbstub.c.bkp +353d352 +< case IDX_SEG_REGS + 8: +354a354 +> case IDX_SEG_REGS + 8: +362,363d361 +< #else +< return 4; \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1860610 b/results/classifier/gemma3:12b/debug/1860610 new file mode 100644 index 000000000..a07e88390 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1860610 @@ -0,0 +1,8 @@ + +cap_disas_plugin leaks memory + +Looking at origin/master head, the function cap_disas_plugin leaks memory. + +per capstone's examples using their ABI, cs_free(insn, count); needs to called just before cs_close. + +I discovered this running qemu under valgrind. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1863445 b/results/classifier/gemma3:12b/debug/1863445 new file mode 100644 index 000000000..f99870de0 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1863445 @@ -0,0 +1,17 @@ + +assertion failed at translate-all.c:2523 with version 3.1.1 + +I was trying to debug a userspace binary with radare2 and met the following assertion in qemu: + +``` +qemu-mipsel: /builddir/build/BUILD/qemu-3.1.1/accel/tcg/translate-all.c:2523: page_check_range: Assertion `start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)' failed. +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7fd1c11c5987 +``` + +``` +# qemu-mipsel --version +qemu-mipsel version 3.1.1 (qemu-3.1.1-2.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers +``` + +not much to add. seems like qemu is not properly checking for valid addresses \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1863486 b/results/classifier/gemma3:12b/debug/1863486 new file mode 100644 index 000000000..5d3181cc3 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1863486 @@ -0,0 +1,74 @@ + +aarch64/tcg crash with malloc(): unsorted double linked list corrupted + +Based on commit b29c3e23f64938784c42ef9fca896829e3c19120, +QEMU configured with --enable-debug --extra-cflags=-ggdb. + +Download Raspberry Pi 3 UEFI Firmware v1.15 from: +https://github.com/pbatard/RPi3/releases/tag/v1.15 +(unzip RPi3_UEFI_Firmware_v1.15.zip) + +Run QEMU with: + +$ qemu-system-aarch64 -M raspi3 \ + -serial null -serial stdio \ + -device loader,file=RPI_EFI.fd,force-raw=true + +Normal behavior: + +NOTICE: Booting Trusted Firmware +NOTICE: BL1: v2.1(release):v2.1 +NOTICE: BL1: Built : 15:26:06, May 13 2019 +NOTICE: rpi3: Detected: Raspberry Pi 3 Model B (1GB, Sony, UK) [0x00a02082] +NOTICE: BL1: Booting BL2 +ERROR: rpi3_sdhost: timeout status 0x40 +NOTICE: BL2: v2.1(release):v2.1 +NOTICE: BL2: Built : 15:26:01, May 13 2019 +NOTICE: BL1: Booting BL31 +NOTICE: BL31: v2.1(release):v2.1 +NOTICE: BL31: Built : 15:26:04, May 13 2019 +=UEFI firmware (version UEFI Firmware v1.15 built at 11:58:44 on Feb 14 2020) +======== + +Synchronous Exception at 0x0000000037A1A4E8 + +But I sometimes get: + +NOTICE: Booting Trusted Firmware +NOTICE: BL1: v2.1(release):v2.1 +NOTICE: BL1: Built : 15:26:06, May 13 2019 +NOTICE: rpi3: Detected: Raspberry Pi 3 Model B (1GB, Sony, UK) [0x00a02082] +NOTICE: BL1: Booting BL2 +ERROR: rpi3_sdhost: timeout status 0x40 +NOTICE: BL2: v2.1(release):v2.1 +NOTICE: BL2: Built : 15:26:01, May 13 2019 +NOTICE: BL1: Booting BL31 +NOTICE: BL31: v2.1(release):v2.1 +NOTICE: BL31: Built : 15:26:04, May 13 2019 +=UEFI firmware (version UEFI Firmware v1.15 built at 11:58:44 on Feb 14 2020) +========malloc(): unsorted double linked list corrupted + +Thread 3 "qemu-system-aar" received signal SIGABRT, Aborted. +[Switching to Thread 0x7fffe9c22700 (LWP 22746)] +0x00007ffff515ce35 in raise () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff515ce35 in raise () at /lib64/libc.so.6 +#1 0x00007ffff5147895 in abort () at /lib64/libc.so.6 +#2 0x00007ffff51a008f in __libc_message () at /lib64/libc.so.6 +#3 0x00007ffff51a740c in () at /lib64/libc.so.6 +#4 0x00007ffff51aa48c in _int_malloc () at /lib64/libc.so.6 +#5 0x00007ffff51aad4e in _int_memalign () at /lib64/libc.so.6 +#6 0x00007ffff51abdda in _mid_memalign () at /lib64/libc.so.6 +#7 0x00007ffff51ad3c6 in posix_memalign () at /lib64/libc.so.6 +#8 0x00007ffff7be2407 in slab_allocator_alloc_chunk () at /lib64/libglib-2.0.so.0 +#9 0x00007ffff7be3573 in g_slice_alloc () at /lib64/libglib-2.0.so.0 +#10 0x00007ffff7bf410a in g_tree_insert_internal () at /lib64/libglib-2.0.so.0 +#11 0x0000555555853f10 in tcg_tb_insert (tb=0x7fffd44b4d80 <code_gen_buffer+4934995>) at tcg/tcg.c:425 +#12 0x00005555558dbe3d in tb_gen_code (cpu=0x555556afa640, pc=933332960, cs_base=0, flags=2216689664, cflags=-16252928) at accel/tcg/translate-all.c:1875 +#13 0x00005555558d7c73 in tb_find (cpu=0x555556afa640, last_tb=0x7fffd44b4c40 <code_gen_buffer+4934675>, tb_exit=0, cf_mask=524288) at accel/tcg/cpu-exec.c:406 +#14 0x00005555558d8543 in cpu_exec (cpu=0x555556afa640) at accel/tcg/cpu-exec.c:730 +#15 0x00005555558981e1 in tcg_cpu_exec (cpu=0x555556afa640) at cpus.c:1405 +#16 0x0000555555898a37 in qemu_tcg_cpu_thread_fn (arg=0x555556afa640) at cpus.c:1713 +#17 0x0000555556057af8 in qemu_thread_start (args=0x555557511570) at util/qemu-thread-posix.c:519 +#18 0x00007ffff52f34c0 in start_thread () at /lib64/libpthread.so.0 +#19 0x00007ffff5221163 in clone () at /lib64/libc.so.6 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1866577 b/results/classifier/gemma3:12b/debug/1866577 new file mode 100644 index 000000000..e239cedf7 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1866577 @@ -0,0 +1,14 @@ + +powerpc-none-eabi-gdb.exe GDB 9.1 with QEMU 4.2 gdb-stub comes with Reply contains invalid hex digit 79 + +I am using powerpc-none-eabi-gdb with qemu 4.2, but it comes with +the following error: + +undefinedC:\CI-Tools\msys64\powerpc-none-eabi\usr\local\bin\powerpc-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. + +```Not implemented stop reason (assuming exception): undefined``` +The target architecture is assumed to be powerpc:603 + +``` +Reply contains invalid hex digit 79 +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1868116 b/results/classifier/gemma3:12b/debug/1868116 new file mode 100644 index 000000000..df47d2fdd --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1868116 @@ -0,0 +1,44 @@ + +QEMU monitor no longer works + +It was observed that the QEMU console (normally accessible using Ctrl+Alt+2) accepts no input, so it can't be used. This is being problematic because there are cases where it's required to send commands to the guest, or key combinations that the host would grab (as Ctrl-Alt-F1 or Alt-F4). + +ProblemType: Bug +DistroRelease: Ubuntu 20.04 +Package: qemu 1:4.2-3ubuntu2 +Uname: Linux 5.6.0-rc6+ x86_64 +ApportVersion: 2.20.11-0ubuntu20 +Architecture: amd64 +CurrentDesktop: XFCE +Date: Thu Mar 19 12:16:31 2020 +Dependencies: + +InstallationDate: Installed on 2017-06-13 (1009 days ago) +InstallationMedia: Xubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412) +KvmCmdLine: + COMMAND STAT EUID RUID PID PPID %CPU COMMAND + qemu-system-x86 Sl+ 1000 1000 34275 25235 29.2 qemu-system-x86_64 -m 4G -cpu Skylake-Client -device virtio-vga,virgl=true,xres=1280,yres=720 -accel kvm -device nec-usb-xhci -serial vc -serial stdio -hda /home/usuario/Sistemas/androidx86.img -display gtk,gl=on -device usb-audio + kvm-nx-lpage-re S 0 0 34284 2 0.0 [kvm-nx-lpage-re] + kvm-pit/34275 S 0 0 34286 2 0.0 [kvm-pit/34275] +MachineType: LENOVO 80UG +ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.6.0-rc6+ root=UUID=6b4ae5c0-c78c-49a6-a1ba-029192618a7a ro quiet ro kvm.ignore_msrs=1 kvm.report_ignored_msrs=0 kvm.halt_poll_ns=0 kvm.halt_poll_ns_grow=0 i915.enable_gvt=1 i915.fastboot=1 cgroup_enable=memory swapaccount=1 zswap.enabled=1 zswap.zpool=z3fold resume=UUID=a82e38a0-8d20-49dd-9cbd-de7216b589fc log_buf_len=16M usbhid.quirks=0x0079:0x0006:0x100000 config_scsi_mq_default=y scsi_mod.use_blk_mq=1 mtrr_gran_size=64M mtrr_chunk_size=64M nbd.nbds_max=2 nbd.max_part=63 +SourcePackage: qemu +UpgradeStatus: Upgraded to focal on 2019-12-22 (87 days ago) +dmi.bios.date: 08/09/2018 +dmi.bios.vendor: LENOVO +dmi.bios.version: 0XCN45WW +dmi.board.asset.tag: NO Asset Tag +dmi.board.name: Toronto 4A2 +dmi.board.vendor: LENOVO +dmi.board.version: SDK0J40679 WIN +dmi.chassis.asset.tag: NO Asset Tag +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Lenovo ideapad 310-14ISK +dmi.modalias: dmi:bvnLENOVO:bvr0XCN45WW:bd08/09/2018:svnLENOVO:pn80UG:pvrLenovoideapad310-14ISK:rvnLENOVO:rnToronto4A2:rvrSDK0J40679WIN:cvnLENOVO:ct10:cvrLenovoideapad310-14ISK: +dmi.product.family: IDEAPAD +dmi.product.name: 80UG +dmi.product.sku: LENOVO_MT_80UG_BU_idea_FM_Lenovo ideapad 310-14ISK +dmi.product.version: Lenovo ideapad 310-14ISK +dmi.sys.vendor: LENOVO +mtime.conffile..etc.apport.crashdb.conf: 2019-08-29T08:39:36.787240 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1869497 b/results/classifier/gemma3:12b/debug/1869497 new file mode 100644 index 000000000..3d6e062fb --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1869497 @@ -0,0 +1,11 @@ + +x86_cpu_gdb_read_register segfaults when gdb requests registers + +When attempting to attach to the gdbstub, a segfault occurs. + +I traced this down to a problem in a call to gdb_get_reg16 where the mem_buf +was being treated like a uint8_t* instead of a GByteArray. The buffer passed +to gdb_get_reg16 ends up passing an invalid GByteArray pointer, which subsequently +causes a segfault in memcpy. + +I have a fix for this - just need to educate myself on how to submit a patch. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1873898 b/results/classifier/gemma3:12b/debug/1873898 new file mode 100644 index 000000000..81eadb9e3 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1873898 @@ -0,0 +1,39 @@ + +arm linux-user: bkpt insn doesn't cause SIGTRAP + +QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signals. Test case: + +===begin bkpt.c=== +/* test bkpt insn */ + +#include <stdlib.h> +#include <stdio.h> + +int main(void) +{ + printf("breakpoint\n"); +#ifdef __aarch64__ + __asm__ volatile("brk 0x42\n"); +#else + __asm__ volatile("bkpt 0x42\n"); +#endif + printf("done\n"); + return 0; +} +===endit=== + +Compile with +$ arm-linux-gnueabihf-gcc -g -Wall -o bkpt-aa32 bkpt.c +$ aarch64-linux-gnu-gcc -g -Wall -o bkpt-aa64 bkpt.c + +Contrast aarch64 which delivers the SIGTRAP and arm which doesn't: + +$ qemu-aarch64 bkpt-aa64 +breakpoint +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +Trace/breakpoint trap (core dumped) +$ qemu-arm bkpt-aa32 +breakpoint +done + +This is because in linux-user/arm/cpu-loop.c we incorrectly treat EXCP_BKPT similarly to EXCP_SWI, which means that we actually perform a syscall (which one depends on what happens to be in r7...). This code has been like this (more or less) since commit 06c949e62a098f in 2006 which added BKPT in the first place. This is probably because at the time the same code path was used to handle both Linux syscalls and semihosting calls, and (on M profile) BKPT does imply a semihosting call. But these days we've moved handling of semihosting out to an entirely different codepath, so we can fix this bug by simply removing this handling of EXCP_BKPT and instead making it deliver a SIGTRAP like EXCP_DEBUG (as we do already on aarch64). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1876373 b/results/classifier/gemma3:12b/debug/1876373 new file mode 100644 index 000000000..30311d262 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1876373 @@ -0,0 +1,49 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1877136 b/results/classifier/gemma3:12b/debug/1877136 new file mode 100644 index 000000000..ba74eac3b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1877136 @@ -0,0 +1,57 @@ + +Qemu GDB Arm core registers XML description not valid for M-profile + +When trying to debug an armv7-m binary running on Qemu, GDB makes some mistakes due to mistakenly believing the target is not M-profile. + +One observable is that backtraces over signal handlers are not handled correctly -- since the special M-profile EXC_RETURN value is not recognised. That happens because GDB doesn't think the target is M-profile. + +This happens because GDB sees a reported feature set from the Qemu remote connection that includes the feature `org.gnu.gdb.arm.core`. + +As described in the GDB online docs, for "M-profile targets (e.g. Cortex-M3), the ‘org.gnu.gdb.arm.core’ feature is replaced by ‘org.gnu.gdb.arm.m-profile’" +https://sourceware.org/gdb/current/onlinedocs/gdb/ARM-Features.html + +From a scan of the Qemu source code on commit ea1329bb3a8d5cd25b70e3dbf73e7ded4d5ad756 it seems that when emulating an arm core it uses `arm-core.xml` unconditionally for `CPUClass->gdb_core_xml_file`, and that means the only feature provided is `org.gnu.gdb.arm.core`. + +Note that even though there is a command to set the architecture in GDB, setting the target architecture to an M-profile core is still not a valid workaround. +This is because the target description overrides everything in setting the `is_m` attribute within GDB. + +Reproduction of the observable: +Using the examples here https://git.linaro.org/people/peter.maydell/m-profile-tests.git/tree/ . +Build the examples, and run +``` +qemu-system-arm -s -S -no-reboot -M lm3s6965evb -m 16 -serial stdio -display none -net nic -net user,restrict=on -d guest_errors,unimp -kernel test3-kern.bin +``` + +Then in a GDB session +``` +vshcmd: > arm-none-eabi-gdb -q +(gdb) +vshcmd: > file test3-kern.elf +Reading symbols from test3-kern.elf... +(gdb) +vshcmd: > target remote localhost:1234 +Remote debugging using localhost:1234 +_start () at init-m.S:53 +53 mov r0, #0 +(gdb) +vshcmd: > show architecture +The target architecture is set automatically (currently armv7) +(gdb) +vshcmd: > break svc +Breakpoint 1 at 0x6fc: svc. (2 locations) +(gdb) +vshcmd: > cont +Continuing. + +Breakpoint 1, svc () at test3.c:16 +16 int test = SEQ(); +(gdb) +vshcmd: > bt +#0 svc () at test3.c:16 +#1 0xfffffff8 in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) +vshcmd: > print/x $lr +$1 = 0xfffffff9 +(gdb) +``` \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1878348 b/results/classifier/gemma3:12b/debug/1878348 new file mode 100644 index 000000000..c44c0016e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1878348 @@ -0,0 +1,19 @@ + +--static build fails in v5.0 (since 5010cec2bc87dafab39b3913c8ca91f88df9c540) + +Hi, + +Since commit 5010cec2bc87dafab39b3913c8ca91f88df9c540, building qemu fails when configured with --static (eg ../configure --target-list=x86_64-softmmu,x86_64-linux-user --enable-debug --static). + +On ubuntu 16.04, it fails to find -lffi and -lselinux. + +After I apt-get install libffi-dev libselinux1-dev, the build still fails: +../backends/dbus-vmstate.o: In function `_nocheck__trace_dbus_vmstate_pre_save': +/home/christophe.lyon/src/qemu/build-static/backends/trace.h:29: undefined reference to `_TRACE_DBUS_VMSTATE_PRE_SAVE_DSTATE' +../backends/dbus-vmstate.o: In function `_nocheck__trace_dbus_vmstate_post_load': +/home/christophe.lyon/src/qemu/build-static/backends/trace.h:52: undefined reference to `_TRACE_DBUS_VMSTATE_POST_LOAD_DSTATE' +../backends/dbus-vmstate.o: In function `_nocheck__trace_dbus_vmstate_loading': +/home/christophe.lyon/src/qemu/build-static/backends/trace.h:75: undefined reference to `_TRACE_DBUS_VMSTATE_LOADING_DSTATE' +../backends/dbus-vmstate.o: In function `_nocheck__trace_dbus_vmstate_saving': +/home/christophe.lyon/src/qemu/build-static/backends/trace.h:98: undefined reference to `_TRACE_DBUS_VMSTATE_SAVING_DSTATE' +collect2: error: ld returned 1 exit status \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1881729 b/results/classifier/gemma3:12b/debug/1881729 new file mode 100644 index 000000000..c673c2610 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1881729 @@ -0,0 +1,4 @@ + +target_read_memory in disas.c ignores possible errors + +`target_read_memory` in `disas.c` ignores (possible) errors. This leads to disassembler possibly disassembling garbage. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1885332 b/results/classifier/gemma3:12b/debug/1885332 new file mode 100644 index 000000000..5ff7f1f75 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1885332 @@ -0,0 +1,95 @@ + +Error in user-mode calculation of ELF aux vector's AT_PHDR + + +I have an (admittedly strange) statically-linked ELF binary for Linux that runs just fine on top of the Linux kernel in QEMU full-system emulation, but crashes before main in user-mode emulation. Specifically, it crashes when initializing thread-local storage in glibc's _dl_aux_init, because it reads out a strange value from the AT_PHDR entry of the ELF aux vector. + +The binary has these program headers: + + Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + EXIDX 0x065874 0x00075874 0x00075874 0x00570 0x00570 R 0x4 + PHDR 0x0a3000 0x00900000 0x00900000 0x00160 0x00160 R 0x1000 + LOAD 0x0a3000 0x00900000 0x00900000 0x00160 0x00160 R 0x1000 + LOAD 0x000000 0x00010000 0x00010000 0x65de8 0x65de8 R E 0x10000 + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + NOTE 0x000114 0x00010114 0x00010114 0x00044 0x00044 R 0x4 + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x8 + GNU_RELRO 0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R 0x1 + LOAD 0x07e000 0x00089000 0x00089000 0x03f44 0x03f44 R E 0x1000 + LOAD 0x098000 0x00030000 0x00030000 0x01000 0x01000 RW 0x1000 + +If I build the Linux kernel with the following patch to the very end of create_elf_tables in fs/binfmt_elf.c + + /* Put the elf_info on the stack in the right place. */ + elf_addr_t *my_auxv = (elf_addr_t *) mm->saved_auxv; + int i; + for (i = 0; i < 15; i++) { + printk("0x%x = 0x%x", my_auxv[2*i], my_auxv[(2*i)+ 1]); + } + if (copy_to_user(sp, mm->saved_auxv, ei_index * sizeof(elf_addr_t))) + return -EFAULT; + return 0; + +and run it like this: + + qemu-system-arm \ + -M versatilepb \ + -nographic \ + -dtb ./dts/versatile-pb.dtb \ + -kernel zImage \ + -M versatilepb \ + -m 128M \ + -append "earlyprintk=vga,keep" \ + -initrd initramfs + +after I've built the kernel initramfs like this (where "init" is the binary in question): + + make ARCH=arm versatile_defconfig + make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- all -j10 + cp "$1" arch/arm/boot/init + cd arch/arm/boot + echo init | cpio -o --format=newc > initramfs + +then I get the following output. This is the kernel's view of the aux vector for this binary: + + 0x10 = 0x1d7 + 0x6 = 0x1000 + 0x11 = 0x64 + 0x3 = 0x900000 + 0x4 = 0x20 + 0x5 = 0xb + 0x7 = 0x0 + 0x8 = 0x0 + 0x9 = 0x101b8 + 0xb = 0x0 + 0xc = 0x0 + 0xd = 0x0 + 0xe = 0x0 + 0x17 = 0x0 + 0x19 = 0xbec62fb5 + +However, if I run "qemu-arm -g 12345 binary" and use GDB to peek at the aux vector at the beginning of __libc_start_init (for example, using this Python GDB API script: https://gist.github.com/langston-barrett/5573d64ae0c9953e2fa0fe26847a5e1e), then I see the following values: + + AT_PHDR = 0xae000 + AT_PHENT = 0x20 + AT_PHNUM = 0xb + AT_PAGESZ = 0x1000 + AT_BASE = 0x0 + AT_FLAGS = 0x0 + AT_ENTRY = 0x10230 + AT_UID = 0x3e9 + AT_EUID = 0x3e9 + AT_GID = 0x3e9 + AT_EGID = 0x3e9 + AT_HWCAP = 0x1fb8d7 + AT_CLKTCK = 0x64 + AT_RANDOM = -0x103c0 + AT_HWCAP2 = 0x1f + AT_NULL = 0x0 + +The crucial difference is in AT_PHDR (0x3), which is indeed the virtual address of the PHDR segment when the kernel calculates it, but is not when QEMU calculates it. + +qemu-arm --version +qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.26) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1885827 b/results/classifier/gemma3:12b/debug/1885827 new file mode 100644 index 000000000..2eaaae418 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1885827 @@ -0,0 +1,80 @@ + +building plugin failed on Windows with mingw + +I want to build QEMU 4.2.0's plugin module on Windows 7/10 with Mingw, but the building process faild. + +The step I follow is listed below: +1. create "dsp_build" diretory under source file folder + +2. change directory to dsp_build , and run ../configure --target-list=dsp-softmmu --cross-prefix=x86_64-w64-mingw32- --enable-gtk --enable-sdl --enable-debug --enable-plugins +3. build qemu project +4. switch dir to /dsp_build, make -C tests/plugin, yeilds error: + CC bb.o + D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:17:24: error: variable 'qemu_plugin_version' definition is marked dllimport + 17 | QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION; + | ^~~~~~~~~~~~~~~~~~~ + D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:17:24: warning: 'qemu_plugin_version' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] + D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c: In function 'vcpu_tb_exec': + D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:33:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] + 33 | unsigned long n_insns = (unsigned long)udata; + | ^ + D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c: In function 'vcpu_tb_trans': + D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:51:46: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] + 51 | (void *)n_insns); + +5. Then , I modified the QEMU_flags and the compilation command arguments($(CC) ..) in the makefile : + + BUILD_DIR := $(CURDIR)/../.. + + include $(BUILD_DIR)/config-host.mak + include $(SRC_PATH)/rules.mak + + $(call set-vpath, $(SRC_PATH)/tests/plugin) + + NAMES := + NAMES += bb + NAMES += empty + NAMES += insn + NAMES += mem + NAMES += hotblocks + NAMES += howvec + NAMES += hotpages + + SONAMES := $(addsuffix .so,$(addprefix lib,$(NAMES))) + + QEMU_CFLAGS += -fPIC -DBUILDING_DLL #added -DBUILDING_DLL + QEMU_CFLAGS += -I$(SRC_PATH)/include/qemu + + all: $(SONAMES) + + lib%.so: %.o + $(CC) -fPIC -shared -o $@ $^ $(LDLIBS) -L /c/msys64/mingw64/lib/ -lglib-2.0 + # original cmd: $(CC) -shared -Wl,-soname,$@ -o $@ $^ $(LDLIBS) + + clean: + rm -f *.o *.so *.d + rm -Rf .libs + + .PHONY: all clean + +6. Executing make yeilds: + +make: enter “/d/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/build_dsp/tests/plugin” + CC bb.o +x86_64-w64-mingw32-gcc -fPIC -shared -o libbb.so bb.o -L /c/msys64/mingw64/lib/ -lglib-2.0 +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `plugin_exit': +D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:28: undefined reference to `qemu_plugin_outs' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:29: undefined reference to `__stack_chk_fail' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `vcpu_tb_trans': +D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:41: undefined reference to `qemu_plugin_tb_n_insns' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:44: undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:46: undefined reference to `qemu_plugin_register_vcpu_tb_exec_inline' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:49: undefined reference to `qemu_plugin_register_vcpu_tb_exec_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o: in function `qemu_plugin_install': +D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:63: undefined reference to `qemu_plugin_register_vcpu_tb_trans_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/emu_devl/qemu_src/qemu-sr-dsp-a/qemu_tidsp_c3x/tests/plugin/bb.c:64: undefined reference to `qemu_plugin_register_atexit_cb' +C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: bb.o:bb.c:(.rdata$.refptr.__stack_chk_guard[.refptr.__stack_chk_guard]+0x0): undefined reference to `__stack_chk_guard' +collect2.exe: error: ld returned 1 exit status + + It looks like linking problem(fail to link functions defined in api.c, core.c...), but I have no idea what goes wrong. If I mannualy add api.o, core.o in the compilation command, still get error like undefined reference to '__stack_chk_guard'. + My collegue can build 4.2.0 plugins on Ubuntu Linux without any problem. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1887820 b/results/classifier/gemma3:12b/debug/1887820 new file mode 100644 index 000000000..49e4831f9 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1887820 @@ -0,0 +1,8 @@ + +TCG test targets missing from 'make check-help' + +We can run the TCG tests using: + +$ make run-tcg-tests-$TARGET-softmmu + +This is not listed in 'make check-help'. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1889411 b/results/classifier/gemma3:12b/debug/1889411 new file mode 100644 index 000000000..68bbe930b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1889411 @@ -0,0 +1,64 @@ + +RISC-V: Unable to unwind the stack upon signals + +Consider the following program: + +=============================================================== +#include <stdio.h> +#include <stdlib.h> + +#define NOINLINE __attribute__ ((noinline)) + +void NOINLINE abort_me(void) { abort(); /* trigger SIGABRT */ } + +void NOINLINE level1(void) { abort_me(); } + +void NOINLINE level2(void) { level1(); } + +void NOINLINE level3(void) { level2(); } + +void NOINLINE level4(void) { level3();} + +int main(void) { + level4(); + return 0; +} +=============================================================== + +$ riscv64-linux-gnu-gcc -march=rv64imafdc -O0 -g c.c +$ qemu-riscv64 -g 31337 ./c & +$ riscv64-unknown-linux-gnu-gdb -q -ex 'target remote localhost:31337' -ex 'b abort_me' -ex c -ex bt ./c +Reading symbols from c... +Remote debugging using localhost:31337 +Reading symbols from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1... +0x0000004000804f30 in _start () from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1 +Breakpoint 1 at 0x4000000632: file c.c, line 7. +Continuing. + +Breakpoint 1, abort_me () at c.c:7 +7 abort(); /* trigger SIGABRT */ +#0 abort_me () at c.c:7 +#1 0x0000004000000642 in level1 () at c.c:11 +#2 0x0000004000000658 in level2 () at c.c:15 +#3 0x000000400000066e in level3 () at c.c:19 +#4 0x0000004000000684 in level4 () at c.c:23 +#5 0x000000400000069a in main () at c.c:27 +=============================================================== + +So far so good, I get a proper backtrace as expected. If I let the signal trigger however, gdb is not able to unwind the stack: + +(gdb) c +Continuing. + +Program received signal SIGABRT, Aborted. +0x0000004000858074 in ?? () +(gdb) bt +#0 0x0000004000858074 in ?? () + + + +I get the same behaviour for SIGSEGV and SIGILL, I didn't try other signals. Apparently this scenario works on real hardware (see linked gdb issue below), and presumably it would work with system qemu (I haven't tested that yet though). So my guess is that qemu does something differently around signal handling than the linux kernel. + + +Full reproducer: https://gist.github.com/lewurm/befb9ddf5894bad9628b1df77258598b +RISC-V GDB issue: https://github.com/riscv/riscv-binutils-gdb/issues/223 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1893691 b/results/classifier/gemma3:12b/debug/1893691 new file mode 100644 index 000000000..7108ae74c --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1893691 @@ -0,0 +1,68 @@ + +Chardev logfile is not written (regression between 5.0 and 5.1) + +After update from version 5.0 to 5.1, logfile stopped being populated with console output. The file is being created, but remains empty. + +Relevant command line options: + +-mon chardev=char0 +-serial chardev:char0 +-chardev socket,host=127.0.0.10,port=2323,server,nowait,telnet,mux=on,id=char0,logfile=/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0/internal/log + + +Full command line: + +qemu-system-x86_64 +-nodefaults +-no-user-config +-snapshot +-enable-kvm +-cpu +host +-nographic +-echr +17 +-mon +chardev=char0 +-serial +chardev:char0 +-rtc +clock=vm +-object +rng-random,filename=/dev/urandom,id=rng0 +-device +virtio-rng-pci,rng=rng0,max-bytes=512,period=1000 +-name +2020-08-31T21:46:55-0,debug-threads=on +-smp +sockets=1,cores=9,threads=2 +-m +251G +-overcommit +cpu-pm=on +-pidfile +/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0/internal/pid +-net +nic,model=virtio +-net +user,hostfwd=tcp:127.0.0.10:2222-:22,hostfwd=tcp:127.0.0.10:8000-:8000,hostfwd=tcp:127.0.0.10:9000-:9000 +-fsdev +local,id=machiner_internal_dir,security_model=none,path=/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0/internal +-device +virtio-9p-pci,fsdev=machiner_internal_dir,mount_tag=machiner_internal_dir +-fsdev +local,id=machiner_lower_dir,security_model=none,readonly,path=. +-device +virtio-9p-pci,fsdev=machiner_lower_dir,mount_tag=machiner_lower_dir +-fsdev +local,id=machiner_upper_dir,security_model=mapped-xattr,fmode=0777,dmode=0777,path=/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0 +-device +virtio-9p-pci,fsdev=machiner_upper_dir,mount_tag=machiner_upper_dir +-device +virtio-scsi +-drive +if=none,file=/home/jurkiew/.machiner/images/famtar/image.qcow2,discard=on,id=famtar +-device +scsi-hd,drive=famtar +-chardev +socket,host=127.0.0.10,port=2323,server,nowait,telnet,mux=on,id=char0,logfile=/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0/internal/log \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1893758 b/results/classifier/gemma3:12b/debug/1893758 new file mode 100644 index 000000000..c3d4793cd --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1893758 @@ -0,0 +1,69 @@ + +meson: scary KeyboardInterrupt backtrace displayed + +Pressing ^C while building (calling 'make') sometime displays KeyboardInterrupt exception backtrace (host Fedora 32): + +$ make qemu-system-arm +Generating qemu-version.h with a meson_exe.py custom command +^CTraceback (most recent call last): + File "/usr/bin/meson", line 6, in <module> + from pkg_resources import load_entry_point + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3252, in <module> + def _initialize_master_working_set(): + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3235, in _call_aside + f(*args, **kwargs) + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3277, in _initialize_master_working_set + tuple( + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3278, in <genexpr> + dist.activate(replace=False) + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2782, in activate + fixup_namespace_packages(self.location) + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2295, in fixup_namespace_packages + subpath = _handle_ns(package, path_item) + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2194, in _handle_ns + importer = get_importer(path_item) + File "/usr/lib64/python3.8/pkgutil.py", line 415, in get_importer + importer = sys.path_importer_cache[path_item] +KeyboardInterrupt + + +$ make +[...] +Compiling C object libcommon.fa.p/disas_alpha.c.o +Compiling C object libcommon.fa.p/hw_isa_smc37c669-superio.c.o +Compiling C object libcommon.fa.p/hw_isa_isa-superio.c.o +Compiling C object libcommon.fa.p/hw_char_serial-isa.c.o +Compiling C object libcommon.fa.p/hw_acpi_aml-build-stub.c.o +^CTraceback (most recent call last): + File "/usr/bin/meson", line 6, in <module> + from pkg_resources import load_entry_point + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3252, in <module> +make: *** [Makefile.ninja:994: libcommon.fa.p/disas_alpha.c.o] Interrupt +make: *** [Makefile.ninja:998: libcommon.fa.p/hw_isa_smc37c669-superio.c.o] Interrupt +make: *** [Makefile.ninja:1025: libcommon.fa.p/hw_isa_isa-superio.c.o] Interrupt +make: *** [Makefile.ninja:1069: libcommon.fa.p/hw_char_serial-isa.c.o] Interrupt +make: *** [Makefile.ninja:1102: libcommon.fa.p/hw_acpi_aml-build-stub.c.o] Interrupt +make: *** [Makefile.ninja:2138: qemu-system-alpha.p/softmmu_main.c.o] Interrupt +make: *** [Makefile.ninja:949: libblock.fa.p/block_qcow2.c.o] Interrupt + def _initialize_master_working_set(): + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3235, in _call_aside + f(*args, **kwargs) + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3287, in _initialize_master_working_set + list(map(working_set.add_entry, sys.path)) + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 623, in add_entry + for dist in find_distributions(entry, True): + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2065, in find_on_path + for dist in factory(fullpath): + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2134, in distributions_from_metadata + yield Distribution.from_location( + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2590, in from_location + return cls( + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2571, in __init__ + self._version = safe_version(version) + File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 1331, in safe_version + return str(packaging.version.Version(version)) + File "/usr/lib/python3.8/site-packages/pkg_resources/_vendor/packaging/version.py", line 205, in __init__ + self._version = _Version( + File "<string>", line 1, in __new__ +KeyboardInterrupt +make: *** [Makefile.ninja:875: qemu.syms.stamp] Interrupt \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1896 b/results/classifier/gemma3:12b/debug/1896 new file mode 100644 index 000000000..fd6e6fd00 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1896 @@ -0,0 +1,55 @@ + +Use `qemu_exit()` function instead of `exit()` +Additional information: +I just saw the similar refactoring for the GDB part of QEMU and thought it might be useful in more general case too: https://lore.kernel.org/qemu-devel/20230907112640.292104-1-chigot@adacore.com/T/#m540552946cfa960b34c4d76d2302324f5de8627f + +``` +$ rg "exit\(0" -t c -l +gdbstub/gdbstub.c +qemu-edid.c +subprojects/libvhost-user/libvhost-user.c +semihosting/arm-compat-semi.c +softmmu/async-teardown.c +softmmu/device_tree.c +softmmu/vl.c +softmmu/runstate.c +os-posix.c +dtc/util.c +dtc/dtc.c +dtc/tests/dumptrees.c +qemu-keymap.c +qemu-io.c +contrib/ivshmem-server/main.c +contrib/rdmacm-mux/main.c +tests/qtest/vhost-user-blk-test.c +tests/qtest/fuzz/fuzz.c +tests/qtest/fuzz/generic_fuzz.c +tests/unit/test-seccomp.c +tests/unit/test-rcu-list.c +tests/unit/rcutorture.c +tests/bench/qht-bench.c +tests/bench/atomic64-bench.c +tests/bench/atomic_add-bench.c +tests/unit/test-iov.c +tests/tcg/multiarch/linux/linux-test.c +tests/tcg/aarch64/mte-3.c +tests/tcg/aarch64/pauth-2.c +tests/tcg/aarch64/mte-5.c +tests/tcg/aarch64/mte-6.c +tests/tcg/aarch64/mte-2.c +tests/tcg/cris/libc/check_glibc_kernelversion.c +tests/tcg/cris/libc/check_lz.c +tests/tcg/s390x/signals-s390x.c +tests/tcg/i386/hello-i386.c +tests/tcg/cris/bare/sys.c +tests/tcg/ppc64/mtfsf.c +qemu-nbd.c +net/net.c +hw/nvram/eeprom93xx.c +hw/arm/allwinner-r40.c +hw/rdma/rdma_backend.c +hw/watchdog/watchdog.c +trace/control.c +hw/pci/pci.c +hw/misc/sifive_test.c +``` diff --git a/results/classifier/gemma3:12b/debug/1897680 b/results/classifier/gemma3:12b/debug/1897680 new file mode 100644 index 000000000..96886bc44 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1897680 @@ -0,0 +1,15 @@ + +memory address over 0x2000_7ffc is not accessible in mps2-an505 + +I currently run qemu with the following options +`qemu-system-aarch64 -machine mps2-an505 -cpu cortex-m33 -m 16` + +For some reason, memory address over 0x2000_7ffc is not accessible. +It can be tested in gdb as follow. + +(gdb) x/x 0x20007ffc +0x20007ffc: 0x00000000 +(gdb) x/x 0x20007ffd +0x20007ffd: Cannot access memory at address 0x20007ffd +(gdb) x/x 0x20008000 +0x20008000: Cannot access memory at address 0x20008000 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1900779 b/results/classifier/gemma3:12b/debug/1900779 new file mode 100644 index 000000000..2ded3f03c --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1900779 @@ -0,0 +1,44 @@ + +xp /16i on arm mixes DWords + +I was working with qemuand wanted to understag ATAG structure. +In Monitor mode I used xp /16i 0x100 and I got really confused. +with xp /16i 0x100: +At address 0x120 the DWords are 0x00000000, 0x00000004, 0x54410009, 0x74736574 +with xp /16x 0x100: +At address 0x120 the DWords are 0x54410001, 0x00000001, 0x00000001, 0x00000000 + +from my Terminal: + +(qemu) xp /16x 0x100 +0000000000000100: 0x00000005 0x54410001 0x00000001 0x00001000 +0000000000000110: 0x00000000 0x00000004 0x54410002 0x3c000000 +0000000000000120: 0x00000000 0x00000004 0x54410009 0x74736574 +0000000000000130: 0x00000000 0x00000000 0x00000000 0x00000000 +(qemu) xp /16i 0x100 +0x00000100: 00000005 andeq r0, r0, r5 +0x00000104: 54410001 strbpl r0, [r1], #-1 +0x00000108: 00000001 andeq r0, r0, r1 +0x0000010c: 00001000 andeq r1, r0, r0 +0x00000110: 00000000 andeq r0, r0, r0 +0x00000114: 00000004 andeq r0, r0, r4 +0x00000118: 54410002 strbpl r0, [r1], #-2 +0x0000011c: 3c000000 .byte 0x00, 0x00, 0x00, 0x3c +0x00000120: 54410001 strbpl r0, [r1], #-1 +0x00000124: 00000001 andeq r0, r0, r1 +0x00000128: 00001000 andeq r1, r0, r0 +0x0000012c: 00000000 andeq r0, r0, r0 +0x00000130: 00000004 andeq r0, r0, r4 +0x00000134: 54410002 strbpl r0, [r1], #-2 +0x00000138: 3c000000 .byte 0x00, 0x00, 0x00, 0x3c +0x0000013c: 00000000 andeq r0, r0, r0 +(increasing length only results in more 00000000 andeq r0, r0, r0 Lines) + +Version: +4.2.1Debian 1:4.2-3ubuntu6.6 +Commandline: +qemu-system-arm -machine raspi2 --nographic -S -s -kernel ./vmlinuz --append "test" +./vmlinuz is a x64 linux kernel. I didn't care about architecture because i just wanted to see ATAG structure. +I also tried +qemu-system-arm -machine raspi2 --nographic -S -s -kernel ./overview.pdf --append "test" +same result. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1905 b/results/classifier/gemma3:12b/debug/1905 new file mode 100644 index 000000000..f08638f87 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1905 @@ -0,0 +1,4 @@ + +Allow for copying text from serial output +Additional information: +In addition to the serial output, it would be beneficial if this copy feature could also be extended to the QEMU monitor and parallel output. diff --git a/results/classifier/gemma3:12b/debug/1907210 b/results/classifier/gemma3:12b/debug/1907210 new file mode 100644 index 000000000..1c9d989ef --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1907210 @@ -0,0 +1,19 @@ + +QEMU gdbstub command "?" issue + +I am using some third party GDB client, and I have noticed that every time "?" command is send from the client, QEMU gdbstub removes all break points. This behaviour is not expected since "?" command should only return stop reason. +Here is documentation from official gdb: +‘?’ Indicate the reason the target halted. The reply is the same as for step and +continue. This packet has a special interpretation when the target is in non-stop +mode; see Section E.10 [Remote Non-Stop], page 733. +Reply: See Section E.3 [Stop Reply Packets], page 693, for the reply specifications. + +With some help on the irc, we have been able to pin point the failure point(in attachement file gdbstub.c). +Function that handles "?" command has this comment in it: + /* + * Remove all the breakpoints when this query is issued, + * because gdb is doing an initial connect and the state + * should be cleaned up. + */ +From which it is clear that developer that wrote that code assumed, that because most popular gdb client only uses "?" command at initial connect, it is safe to also remove all BPs. +In my opinion initial connect should be detected in some other way, and not with "?" command. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1909 b/results/classifier/gemma3:12b/debug/1909 new file mode 100644 index 000000000..f71f23430 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1909 @@ -0,0 +1,51 @@ + +regression: 8.0.0 segfaults on coverage counter increment +Description of problem: +With qemu 8.0.0, my test program segfaults while incrementing a gcov counter: + +``` +Breakpoint 2, 0x00000000004bc9a8 in __CortexA53843419_464004 () +(gdb) x/2i $pc +=> 0x4bc9a8 <__CortexA53843419_464004>: str x8, [x9, #2512] + 0x4bc9ac <__CortexA53843419_464004+4>: b 0x464008 <mock_hyp_params_Destroy+24> +(gdb) p $x8 +$10 = 1 +(gdb) p $x9 +$11 = 5234688 +(gdb) x/x $x9+2512 +0x4fe9d0 <__llvm_gcov_ctr.5>: 0x00000000 +(gdb) stepi + +Program received signal SIGSEGV, Segmentation fault. +0x00000000004bc9a8 in __CortexA53843419_464004 () +(gdb) x/x $x9+2512 +0x4fe9d0 <__llvm_gcov_ctr.5>: 0x00000000 +(gdb) shell llvm-objdump --syms --arch-name=aarch64 ./build/gcov/out/test_hyp-props.out | grep 4fe9d0 +00000000004fe9d0 l O .bss 0000000000000008 __llvm_gcov_ctr.5 +(gdb) shell qemu-aarch64 --version +qemu-aarch64 version 8.0.0 +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +(gdb) +``` + +With qemu 6.2.0, it doesn't segfault (at least not at this point, you +may ignore the segfault at the end due to a bug in the test program). +``` +$ /usr/bin/qemu-aarch64 --version +qemu-aarch64 version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.12) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +$ /usr/bin/qemu-aarch64 ./build/gcov/out/test_hyp-props.out +test_hyp-props.c:13:test__setup_str_prop:PASS +test_hyp-props.c:14:test__log_print_handler:PASS +test_hyp-props.c:15:test__setup_log_print_prop:PASS +test_hyp-props.c:16:test__vm_vcpu_abort_reset_handler:PASS +test_hyp-props.c:17:test__vm_info_alloc:PASS +test_hyp-props.c:18:test__memory_status_get:PASS +test_hyp-props.c:19:test__memory_status_get_fail:PASS +Segmentation fault (core dumped) +``` +Steps to reproduce: +1. Compile and link statically (with ld.lld) a test program, with clang, targetting aarch64 with: -target aarch64-linux-android -mcpu=cortex-a53, using --coverage option to generate gcov coverage. +2. Run it with qemu-aarch64 8.0.0 +3. Hopefully, it will segfault early for no good reason. diff --git a/results/classifier/gemma3:12b/debug/1909770 b/results/classifier/gemma3:12b/debug/1909770 new file mode 100644 index 000000000..729bc9de3 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1909770 @@ -0,0 +1,219 @@ + +qemu-cris segfaults upon loading userspace binary + +I am on commit 65a3c5984074313602fb5f61cc5f464abfb020c7 (latest as far as I know). I compiled qemu with --enable-debug. + +I'm trying to run a userspace CRIS binary (`./qemu-cris -cpu crisv10 ./basic`), but this segfaults. When opening the coredump in gdb, I get + +gdb-peda$ bt +#0 0x00007f272a2e1ee1 in __memset_avx2_erms () from /usr/lib/libc.so.6 +#1 0x0000564a2f7bcda7 in zero_bss (elf_bss=0x82134, last_bss=0x84000, + prot=0x3) at ../linux-user/elfload.c:1865 +#2 0x0000564a2f7bff65 in load_elf_image ( + image_name=0x7fffe9f5703d "./basic", image_fd=0x3, + info=0x7fffe9f547c0, pinterp_name=0x7fffe9f545b0, + bprm_buf=0x7fffe9f54920 "\177ELF\001\001\001") + at ../linux-user/elfload.c:2801 +#3 0x0000564a2f7c0a12 in load_elf_binary (bprm=0x7fffe9f54920, + info=0x7fffe9f547c0) at ../linux-user/elfload.c:3104 +#4 0x0000564a2f81f290 in loader_exec (fdexec=0x3, + filename=0x7fffe9f5703d "./basic", argv=0x564a2f9f3cc0, + envp=0x564a2fa12600, regs=0x7fffe9f54860, infop=0x7fffe9f547c0, + bprm=0x7fffe9f54920) at ../linux-user/linuxload.c:147 +#5 0x0000564a2f7c4f9f in main (argc=0x4, argv=0x7fffe9f54e78, + envp=0x7fffe9f54ea0) at ../linux-user/main.c:808 +#6 0x00007f272a1a4152 in __libc_start_main () from /usr/lib/libc.so.6 +#7 0x0000564a2f786cee in _start () + +Or as a full backtrace: +gdb-peda$ bt full +#0 0x00007f272a2e1ee1 in __memset_avx2_erms () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x0000564a2f7bcda7 in zero_bss (elf_bss=0x82134, last_bss=0x84000, + prot=0x3) at ../linux-user/elfload.c:1865 + host_start = 0x92134 + host_map_start = 0x93000 + host_end = 0x94000 +#2 0x0000564a2f7bff65 in load_elf_image ( + image_name=0x7fffe9f5703d "./basic", image_fd=0x3, + info=0x7fffe9f547c0, pinterp_name=0x7fffe9f545b0, + bprm_buf=0x7fffe9f54920 "\177ELF\001\001\001") + at ../linux-user/elfload.c:2801 + vaddr = 0x82134 + vaddr_em = 0x82140 + vaddr_len = 0x2000 + vaddr_po = 0x134 + vaddr_ps = 0x82000 + vaddr_ef = 0x82134 + elf_prot = 0x3 + eppnt = 0x7fffe9f54974 + ehdr = 0x7fffe9f54920 + phdr = 0x7fffe9f54954 + load_addr = 0x80000 + load_bias = 0x0 + loaddr = 0x80000 + hiaddr = 0x1082140 + error = 0x80000 + i = 0x1 + retval = 0x273d2e9c + prot_exec = 0x4 + err = 0x0 + __func__ = "load_elf_image" +#3 0x0000564a2f7c0a12 in load_elf_binary (bprm=0x7fffe9f54920, + info=0x7fffe9f547c0) at ../linux-user/elfload.c:3104 + interp_info = { + load_bias = 0x0, + load_addr = 0x0, + start_code = 0x0, + end_code = 0x0, + start_data = 0x0, + end_data = 0x0, + start_brk = 0x0, + brk = 0x0, + reserve_brk = 0x0, + start_mmap = 0x0, + start_stack = 0x0, + stack_limit = 0x0, + entry = 0x0, + code_offset = 0x0, + data_offset = 0x0, + saved_auxv = 0x0, + auxv_len = 0x0, + arg_start = 0x0, + arg_end = 0x0, + arg_strings = 0x0, + env_strings = 0x0, + file_string = 0x0, + elf_flags = 0x0, + personality = 0x0, + alignment = 0x0, + loadmap_addr = 0x0, + nsegs = 0x0, + loadsegs = 0x0, + pt_dynamic_addr = 0x0, + interpreter_loadmap_addr = 0x0, + interpreter_pt_dynamic_addr = 0x0, + other_info = 0x0, + note_flags = 0x0 + } + elf_ex = { + e_ident = "|\214\t1\000\000\000\000\262\002\356_\000\000\000", + e_type = 0x8c7c, + e_machine = 0x3109, + e_version = 0x0, + e_entry = 0x5fee02b2, + e_phoff = 0x0, + e_shoff = 0x31098c7c, + e_flags = 0x0, + e_ehsize = 0x0, + e_phentsize = 0x0, + e_phnum = 0x0, + e_shentsize = 0x0, + e_shnum = 0x0, + e_shstrndx = 0x0 + } + elf_interpreter = 0x0 + scratch = 0x7f272a358021 <read+97> "H\213D$\bH\203\304(\303\017\037D" +#4 0x0000564a2f81f290 in loader_exec (fdexec=0x3, + filename=0x7fffe9f5703d "./basic", argv=0x564a2f9f3cc0, + envp=0x564a2fa12600, regs=0x7fffe9f54860, infop=0x7fffe9f547c0, + bprm=0x7fffe9f54920) at ../linux-user/linuxload.c:147 + retval = 0x400 +#5 0x0000564a2f7c4f9f in main (argc=0x4, argv=0x7fffe9f54e78, + envp=0x7fffe9f54ea0) at ../linux-user/main.c:808 + regs1 = { + orig_r10 = 0x0, + r0 = 0x0, + r1 = 0x0, + r2 = 0x0, + r3 = 0x0, + r4 = 0x0, + r5 = 0x0, + r6 = 0x0, + r7 = 0x0, + r8 = 0x0, + r9 = 0x0, + r10 = 0x0, + r11 = 0x0, + r12 = 0x0, + r13 = 0x0, + acr = 0x0, + srs = 0x0, + mof = 0x0, + spc = 0x0, + ccs = 0x0, + srp = 0x0, + erp = 0x0, + exs = 0x0, + eda = 0x0 + } + regs = 0x7fffe9f54860 + info1 = { + load_bias = 0x0, + load_addr = 0x80000, + start_code = 0x80000, + end_code = 0x80133, + start_data = 0xffffffff, + end_data = 0x0, + start_brk = 0x0, + brk = 0x80133, + reserve_brk = 0x1000000, + start_mmap = 0x80000000, + start_stack = 0x0, + stack_limit = 0x0, + entry = 0x80106, + code_offset = 0x0, + data_offset = 0x0, + saved_auxv = 0x0, + auxv_len = 0x0, + arg_start = 0x0, + arg_end = 0x0, + arg_strings = 0x0, + env_strings = 0x0, + file_string = 0x0, + elf_flags = 0x0, + personality = 0x0, + alignment = 0x2000, + loadmap_addr = 0x0, + nsegs = 0x2, + loadsegs = 0x0, + pt_dynamic_addr = 0x0, + interpreter_loadmap_addr = 0x0, + interpreter_pt_dynamic_addr = 0x0, + other_info = 0x0, + note_flags = 0x0 + } + info = 0x7fffe9f547c0 + bprm = { + buf = "\177ELF\001\001\001\000\000\000\000\000\000\000\000\000\002\000L\000\001\000\000\000\006\001\b\000\064\000\000\000\264\006\000\000\000\000\000\000\064\000 \000\003\000(\000\016\000\r\000\001\000\000\000\000\000\000\000\000\000\b\000\000\000\b\000\063\001\000\000\063\001\000\000\005\000\000\000\000 \000\000\001\000\000\000\064\001\000\000\064!\b\000\064!\b\000\000\000\000\000\f\000\000\000\006\000\000\000\000 \000\000\004\000\000\000\224\000\000\000\224\000\b\000\224\000\b\000$\000\000\000$\000\000\000\004\000\000\000\004\000\000\000\004\000\000\000\024\000\000\000\003\000\000\000GNU\000PH\017'i\204\231\070e\000\247\376\211\230\236\336Nf7\372\204\342\356\213n\206\214\342\374\201\352\253\370\201\353\273"..., + p = 0x0, + fd = 0x3, + e_uid = 0x3e8, + e_gid = 0x3d9, + argc = 0x1, + envc = 0x43, + argv = 0x564a2f9f3cc0, + envp = 0x564a2fa12600, + filename = 0x7fffe9f5703d "./basic", + core_dump = 0x0 + } + ts = 0x564a2fa25400 + env = 0x564a2fa24a08 + cpu = 0x564a2fa1c730 + optind = 0x3 + target_environ = 0x564a2fa12600 + wrk = 0x7fffe9f550b8 + target_argv = 0x564a2f9f3cc0 + target_argc = 0x1 + i = 0x1 + ret = 0x7fff + execfd = 0x3 + log_mask = 0x0 + max_reserved_va = 0xffffe000 +#6 0x00007f272a1a4152 in __libc_start_main () from /usr/lib/libc.so.6 +No symbol table info available. +#7 0x0000564a2f786cee in _start () +No symbol table info available. + + +The binary itself is just a basic binary that prints "hello\n" to stdout. I have attached it. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1910540 b/results/classifier/gemma3:12b/debug/1910540 new file mode 100644 index 000000000..3ce9d8472 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1910540 @@ -0,0 +1,4 @@ + +where the trace file "trace-*" + +I compile qemu-system-aarch64 with --enable-trace-backends=simple option, then start qemu with -trace nvme* , qemu start successful but I cann't find the trace file "trace-*" at qemu started directory. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1913619 b/results/classifier/gemma3:12b/debug/1913619 new file mode 100644 index 000000000..00aa7ad70 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1913619 @@ -0,0 +1,10 @@ + +qemu-system-x86_64 -cdrom -nographic gives no output + +Running 'sudo qemu-system-x86_64 -m 2048M -cpu host -cdrom github/xvisor-bootable.iso -boot d -enable-kvm' will create a qemu window, boot to a grub prompt and then boot the xvisor binary correctly. + +Once I append -nographic to the command - after the user has selected the grub boot binary, there is no further output. + +I've tried various permutations with qemu options, but to no avail. It would be great to have this working as it will permit scrolling back up into the command history for reference and large data output. + +QEMU emulator version 5.2.50 (v5.2.0-925-g7b09f12773) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1913913 b/results/classifier/gemma3:12b/debug/1913913 new file mode 100644 index 000000000..ebcffcd19 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1913913 @@ -0,0 +1,19 @@ + +i386-linux-user returns -1 in sigcontext->trapno + +QEMU development version, git commit 74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in 5.2.0 generally. + +Certain 16-bit windows programs crash WINE under QEMU linux-user with: + +0084:err:seh:segv_handler Got unexpected trap -1 +wine: Unhandled illegal instruction at address 00006D65 (thread 0084), starting debugger... + +They run correctly on native i386. + +Upon further inspection,it becomes clear these programs are failing at addresses where they are making DOS calls (int 21h ie CD 21 for instance). + +It is also clear that WINE is expecting an exception/signal at this point, to patch in the actual int21h handling code inside WINE. + +However, wine uses sigcontext output extensively to do its structured exception handling. sigcontext->trapno being set to -1 seems to confuse it, causing it to treat the exception as an actual unhandled error. + +I do not know if exception_index is being left at -1 due to the case of privileged instructions being executed in 16-bit ldts not being handled specifically, or if there is some other illegal instruction case causing this. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1914021 b/results/classifier/gemma3:12b/debug/1914021 new file mode 100644 index 000000000..e0081016a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1914021 @@ -0,0 +1,28 @@ + +qemu: uncaught target signal 4 (Illegal instruction) but gdb remote-debug exited normally + +I'm getting Illegal instruction (core dumped) when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +readelf -h a.out_err +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0x8220 + Start of program headers: 52 (bytes into file) + Start of section headers: 54228 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 3 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 15 + +qemu-arm version 4.0.0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1915925 b/results/classifier/gemma3:12b/debug/1915925 new file mode 100644 index 000000000..78adc58f6 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1915925 @@ -0,0 +1,18 @@ + +ARM semihosting HEAPINFO results wrote to wrong address + +This affects latest development branch of QEMU. + +According to the ARM spec of the HEAPINFO semihosting call: + +https://developer.arm.com/documentation/100863/0300/Semihosting-operations/SYS-HEAPINFO--0x16-?lang=en + +> the PARAMETER REGISTER contains the address of a pointer to a four-field data block. + +However, QEMU treated the PARAMETER REGISTER as pointing to a four-field data block directly. + +Here is a simple program that can demonstrate this problem: https://github.com/iNvEr7/qemu-learn/tree/newlib-bug/semihosting-newlib + +This code links with newlib with semihosting mode, which will call the HEAPINFO SVC during crt0 routine. When running in QEMU (make run), it may crash the program either because of invalid write or memory curruption, depending on the compiled program structure. + +Also refer to my discussion with newlib folks: https://sourceware.org/pipermail/newlib/2021/018260.html \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1916506 b/results/classifier/gemma3:12b/debug/1916506 new file mode 100644 index 000000000..bd3645fa9 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1916506 @@ -0,0 +1,17 @@ + +make check-venv may leave stale and incomplete tests/venv directory directory + +As reported by "Philippe Mathieu-Daudé" <email address hidden>, a "make check-venv" can be run and fail to properly create a suitable virtual environment, leaving the tests/venv directory which is the target for "make check-venv" itself. + +This means that on a subsequent run: + +> $ make check-venv +> GIT ui/keycodemapdb tests/fp/berkeley-testfloat-3 +> tests/fp/berkeley-softfloat-3 dtc capstone slirp +> make: Nothing to be done for 'check-venv'. + +And the venv will still be incomplete. The causes of such failures to create a suitable virtual environment are too many (in the reported case it was because of missing *required* Python packages). Some more evolved virtual environments + Python packaging systems exist that could probably be used here (Pipenv) but would add further core requirements. + +The current mitigation is to run "make check-clean" when the venv appears to be incomplete. + +The goal of this bug is to attempt to make the venv setup atomic and more reliable. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1917661 b/results/classifier/gemma3:12b/debug/1917661 new file mode 100644 index 000000000..7c1c34e73 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1917661 @@ -0,0 +1,16 @@ + +qemu gdb wrong registers group for riscv64 + +Step to reproduce: +1. run qemu-system-riscv64 in gdb mode +2. attach gdb +3. set a breakpoint and run +4. print register-groups using "maintenance print register-groups" command + +... + sbadaddr 4162 4162 1628 8 long all,general + msounteren 4163 4163 1636 8 long all,general + mbadaddr 4164 4164 1644 8 long all,general + htimedeltah 4165 4165 1652 8 long all,general + +These registers don't belong to general group, instead they belong to all, system and csr groups. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1918302 b/results/classifier/gemma3:12b/debug/1918302 new file mode 100644 index 000000000..4b28bac2a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1918302 @@ -0,0 +1,13 @@ + +qemu-system-arm segfaults while servicing SYS_HEAPINFO + +I compiled QEMU version 5.2.0 from source on Ubuntu 18.04, and tried to use it to run the attached bare-metal Arm hello-world image, using the command line + +qemu-system-arm -M microbit -semihosting -nographic -device loader,file=hello.hex + +The result was that qemu-system-arm itself died of a segfault. Compiling it for debugging, the location of the segfault was in target/arm/arm-semi.c, in the case handler for the semihosting call TARGET_SYS_HEAPINFO, on line 1020 which assigns to 'rambase': + + const struct arm_boot_info *info = env->boot_info; + target_ulong rambase = info->loader_start; + +and the problem seems to be that 'info', aka env->boot_info, is NULL in this context. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1921092 b/results/classifier/gemma3:12b/debug/1921092 new file mode 100644 index 000000000..3386cc17a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1921092 @@ -0,0 +1,6 @@ + +gdbstub debug of multi-cluster machines is undocumented and confusing + +Working with Zephyr RTOS, running a multi core sample on mps2_an521 works fine. Both cpus start. +Trying to debug with options -s -S the second core fails to boot. +Posted with explanation also at: https://github.com/zephyrproject-rtos/zephyr/issues/33635 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1923693 b/results/classifier/gemma3:12b/debug/1923693 new file mode 100644 index 000000000..9b1cfab76 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1923693 @@ -0,0 +1,18 @@ + +Lack of architecture in gdbstub makes debugging confusing + +I spent some quality time debugging GEF and came to a conclusion here: +https://github.com/hugsy/gef/issues/598#issuecomment-819174169 + +tldr; + +* gdb_arch_name was undefined on riscv +* this bug was fixed recently via https://github.com/qemu/qemu/commit/edf647864bdab84ed4b1a4f47ea05be6bb075c69 + + +* An undefined gdb_arch_name results in qemu's gdbstub omitting the <architecture> xml. +* gdb translates a missing <architecture> as "auto" which breaks a lot of stuff. +* tracking down where "auto" comes from is a bit confusing and time consuming. + + +It might be better to report a missing / blank gdb_arch_name as "<architecture>unknown</architecture>" instead of omitting the block completely. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1944 b/results/classifier/gemma3:12b/debug/1944 new file mode 100644 index 000000000..f420a746a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1944 @@ -0,0 +1,72 @@ + +Deadlock on snapshot removal (bdrv_graph_wrlock) +Description of problem: +VM was hanging during snapshot removal. +There was an attempt to shutdown the VM, but that did hang. + +gdb shows me: +``` +(gdb) bt full +#0 0x00007f20493427fe in __ppoll (fds=0x557e630718b0, nfds=2, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:43 + sc_ret = -514 + sc_cancel_oldtype = 0 + sc_ret = <optimized out> + tval = {tv_sec = 139776632323420, tv_nsec = 139776632323432} +#1 0x0000557e619cab52 in fdmon_poll_wait.llvm () +No symbol table info available. +#2 0x0000557e619ca0b6 in aio_poll () +No symbol table info available. +#3 0x0000557e61801651 in bdrv_graph_wrlock () +No symbol table info available. +#4 0x0000557e617c873b in bdrv_replace_child_noperm.llvm () +No symbol table info available. +#5 0x0000557e617c8601 in bdrv_root_unref_child () +No symbol table info available. +#6 0x0000557e617f6333 in blk_unref () +No symbol table info available. +#7 0x0000557e6181b0d1 in mirror_exit_common () +No symbol table info available. +#8 0x0000557e617dbdb4 in job_do_finalize_locked.llvm () +No symbol table info available. +#9 0x0000557e617dd72b in job_exit () +No symbol table info available. +#10 0x0000557e619e5101 in aio_bh_poll () +No symbol table info available. +#11 0x0000557e619c95a4 in aio_dispatch () +No symbol table info available. +#12 0x0000557e619e655f in aio_ctx_dispatch () +No symbol table info available. +#13 0x00007f2049546e2f in g_main_dispatch (context=0x557e62ecebd0) at ../glib/gmain.c:3337 + dispatch = 0x557e619e6550 <aio_ctx_dispatch> + prev_source = 0x0 + begin_time_nsec = 232172181173336 + was_in_call = <optimized out> + user_data = 0x0 + callback = 0x0 + cb_funcs = 0x0 + cb_data = 0x0 + need_destroy = <optimized out> + source = 0x557e62ec73e0 + current = 0x557e63e4b600 + i = 0 + __func__ = {<optimized out> <repeats 16 times>} +#14 g_main_context_dispatch (context=0x557e62ecebd0) at ../glib/gmain.c:4055 +No locals. +#15 0x0000557e619e74be in main_loop_wait () +No symbol table info available. +#16 0x0000557e615201e7 in qemu_main_loop () +No symbol table info available. +#17 0x0000557e61374c6a in qemu_default_main () +No symbol table info available. +#18 0x00007f204923feb0 in __libc_start_call_main (main=main@entry=0x557e61374c80 <main>, argc=argc@entry=153, argv=argv@entry=0x7ffe07495238) at ../sysdeps/nptl/libc_start_call_main.h:58 + self = <optimized out> + result = <optimized out> + unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -6145724763479124305, 140729020666424, 94001285254272, 94001294953808, 139776661151744, 6145708635144279727, 6121919821307926191}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7f204954cb41 <g_malloc0+33>, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 1230293825}}} + not_first_call = <optimized out> +#19 0x00007f204923ff60 in __libc_start_main_impl (main=0x557e61374c80 <main>, argc=153, argv=0x7ffe07495238, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe07495228) at ../csu/libc-start.c:389 +No locals. +#20 0x0000557e613743d5 in _start () +No symbol table info available. +``` +Steps to reproduce: +Still trying to reproduce in lab. diff --git a/results/classifier/gemma3:12b/debug/1963 b/results/classifier/gemma3:12b/debug/1963 new file mode 100644 index 000000000..db34bf0c0 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1963 @@ -0,0 +1,29 @@ + +EOF is not detected, when semihosting is reading from stdin +Description of problem: +QEMU hangs. +Steps to reproduce: +1. Run the program with stdin from a pipe. +Additional information: +The code is compiled from this source: +``` +#include <stdio.h> + +int main(int argc, char** argv) { + int i = -1; + int result = scanf("%d", &i); + printf("result = %d, i = %d\n", result, i); + return 0; +} +``` +compiled with GCC and picolibc: +``` +arm-none-eabi-gcc --specs=picolibc.specs -march=armv7-m ~/sources/picolibc/git/test-stdin.c -o test-stdin -lc -lsemihost --crt0=hosted -O0 -g +``` +[test-stdin](/uploads/dbd2650c8e0aaca353fd7630ac9c8440/test-stdin) +The execution hangs at semihosting SYS_READC(0x7) call: +``` + movs r0, #7 +(...) + bkpt #0xab +``` diff --git a/results/classifier/gemma3:12b/debug/1967248 b/results/classifier/gemma3:12b/debug/1967248 new file mode 100644 index 000000000..d9e7789f0 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1967248 @@ -0,0 +1,39 @@ + +qemu: uncaught target signal 5 (Trace/breakpoint trap) + +I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal. + +0xa602 <_start> movs r0, #22 0xa604 <_start+2> addw r1, pc, #186 ; 0xba +0xa608 <_start+6> bkpt 0x00ab + +$readelf -h hello +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0xa603 + Start of program headers: 52 (bytes into file) + Start of section headers: 144128 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 5 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 14 + +$qemu-arm --version +qemu-arm version 6.2.0 +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + + +And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. +But it's coredump. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/1976 b/results/classifier/gemma3:12b/debug/1976 new file mode 100644 index 000000000..905fedf0f --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1976 @@ -0,0 +1,50 @@ + +SIGILL (ILL_OPC) on RISC-V Vector Operations, Bad MSTATUS_VS register +Description of problem: +When building AOSP Android and launching the public Cuttlefish RISC-V image, various binaries on the system will crash on boot with SIGILL, ILL_OPC. The crashes are random - binaries will crash largely at boot and then only crash infrequently after that. It is not always the case that the same binary will crash first, but if a binary crashes, it will always crash at the same location, usually the first vector instruction. At the time of writing, this is often the 'vsetvli' or 'vfirst.m' instruction. + +After building QEMU at head and intentionally triggering a SIGABRT prior to the ILL_OPC exception, I caught the following backtrace in gdb: + +``` +(gdb) bt +#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 +#1 0x00007f8e570bb15f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 +#2 0x00007f8e5706d472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#3 0x00007f8e570574b2 in __GI_abort () at ./stdlib/abort.c:79 +#4 0x0000565536e817d7 in vs (env=<optimized out>, csrno=<optimized out>) at ../target/riscv/csr.c:101 +#5 vs (env=<optimized out>, csrno=<optimized out>) at ../target/riscv/csr.c:95 +#6 0x0000565536e83d5b in riscv_csrrw_check (write_mask=false, csrno=3106, env=0x7f8e4e2b0ed0) at ../target/riscv/csr.c:4286 +#7 riscv_csrrw (env=env@entry=0x7f8e4e2b0ed0, csrno=3106, ret_value=ret_value@entry=0x7f8bdedfbee0, new_value=new_value@entry=0, write_mask=write_mask@entry=0) + at ../target/riscv/csr.c:4366 +#8 0x0000565536e86b52 in helper_csrr (env=0x7f8e4e2b0ed0, csr=<optimized out>) at ../target/riscv/op_helper.c:54 +#9 0x00007f8de9f1af73 in code_gen_buffer () +#10 0x0000565536fa39cb in cpu_tb_exec (cpu=cpu@entry=0x7f8e4e2ae710, itb=itb@entry=0x7f8de9f1ab40 <code_gen_buffer+99724051>, tb_exit=tb_exit@entry=0x7f8bdedfc444) + at ../accel/tcg/cpu-exec.c:458 +#11 0x0000565536fa3ea1 in cpu_loop_exec_tb + (tb_exit=0x7f8bdedfc444, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7f8de9f1ab40 <code_gen_buffer+99724051>, cpu=<optimized out>) + at ../accel/tcg/cpu-exec.c:920 +#12 cpu_exec_loop (cpu=cpu@entry=0x7f8e4e2ae710, sc=sc@entry=0x7f8bdedfc4f0) at ../accel/tcg/cpu-exec.c:1041 +#13 0x0000565536fa469d in cpu_exec_setjmp (cpu=cpu@entry=0x7f8e4e2ae710, sc=sc@entry=0x7f8bdedfc4f0) at ../accel/tcg/cpu-exec.c:1058 +#14 0x0000565536fa4c6b in cpu_exec (cpu=cpu@entry=0x7f8e4e2ae710) at ../accel/tcg/cpu-exec.c:1084 +#15 0x0000565536fbfedf in tcg_cpus_exec (cpu=cpu@entry=0x7f8e4e2ae710) at ../accel/tcg/tcg-accel-ops.c:76 +#16 0x0000565536fc0023 in mttcg_cpu_thread_fn (arg=arg@entry=0x7f8e4e2ae710) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#17 0x0000565537144288 in qemu_thread_start (args=0x565538c01840) at ../util/qemu-thread-posix.c:541 +#18 0x00007f8e570b93ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444 +#19 0x00007f8e57139a4c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` + +Debugging in this path, it appears that the reason we're experiencing a SIGILL here is that when building a qemu-system-riscv64 binary (and thus !CONFIG_USER_ONLY), we check to see if 'riscv_cpu_vector_enabled(env)', which checks if `env->mstatus & MSTATUS_VS`. + +Interestingly, logging in this path confirms that the CPU environment of this thread does think the RVV extension is enabled (verified with `riscv_has_ext(env, RVV)`. My rough guess as to what's happening: + +1. We're not setting the MSTATUS_VS flag on initialization of the CPU, nor are we setting the mstatus_vs state to INITIALIZED. Without this, when a new thread is spawned for a vCPU, it's incorrectly determining that it can't handle vector instructions. +2. It's working sometimes because in some of the 'write_*' calls in `riscv/csr.c`, we flip the MSTATUS_VS flag on, so if one of those calls occurs first, all subsequent vector operations work too. (To be honest, I'm not quite following why we make the decision to set MSTATUS in these calls, shouldn't this be configured at CPU initialization?) +Steps to reproduce: +Please forgive the poor reproduction case, I'm still trying to wrap my head around what's going on, so haven't been able to harden a smaller example yet that would reproduce. In theory, tip-of-tree QEMU + a stock Linux system with a program that triggers a call to QEMU's vlenb instruction ahead of all other vector instructions would be the ideal case, but I'm still figuring out how to go about doing that. + +My current reproduction case is as follows: + +1. Introduce a small hack in `target/riscv/csr.c`'s `vs` function - add an `abort` call here: https://github.com/qemu/qemu/blob/master/target/riscv/csr.c#L99 +2. Build tip-of-tree QEMU for qemu-system-riscv64. +3. Use https://github.com/google/android-riscv64#can-i-try-it to build the Android RISC-V emulator. When launching the emulator, use the '-qemu_binary_dir' option to point to the directory containing the QEMU built in the previous step. +4. In a few moments, the emulator will attempt to start but abort fairly quickly (I've got a 128-core machine, and it fails consistently in about 5 seconds). diff --git a/results/classifier/gemma3:12b/debug/1992 b/results/classifier/gemma3:12b/debug/1992 new file mode 100644 index 000000000..914dc8f08 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1992 @@ -0,0 +1,910 @@ + +ReverseDebugging_ppc64 avocado test is not working reliably +Description of problem: +The tests/avocado/reverse_debugging.py:ReverseDebugging_ppc64.test_ppc64_powernv test is sometimes failing in the gitlab-CI. Looking at the logs, it seems like QEMU is dying early here, so this might be a real bug and not only an issue with the test. Full debug.log from the failing job: + +``` +08:28:31 DEBUG| PARAMS (key=arch, path=*, default=ppc64) => 'ppc64' +08:28:31 DEBUG| PARAMS (key=cpu, path=*, default=None) => None +08:28:31 DEBUG| PARAMS (key=qemu_bin, path=*, default=./qemu-system-ppc64) => './qemu-system-ppc64' +08:28:31 DEBUG| PARAMS (key=machine, path=*, default=powernv) => 'powernv' +08:28:31 INFO | creating qcow2 image for VM snapshots +08:28:31 INFO | Running '/builds/thuth/qemu/build/qemu-img create -f qcow2 /builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/disk.qcow2 128M' +08:28:31 DEBUG| [stdout] Formatting '/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/disk.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=134217728 lazy_refcounts=off refcount_bits=16 +08:28:31 INFO | Command '/builds/thuth/qemu/build/qemu-img create -f qcow2 /builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/disk.qcow2 128M' finished with 0 after 0.024550681999926383s +08:28:31 DEBUG| QEMUMachine "1646a50b-5d2a-405b-8636-45a38b5fde30" created +08:28:31 DEBUG| QEMUMachine "1646a50b-5d2a-405b-8636-45a38b5fde30" temp_dir: /builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/qemu-machine-uq5k4nlc +08:28:31 DEBUG| QEMUMachine "1646a50b-5d2a-405b-8636-45a38b5fde30" log_dir: /builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv +08:28:31 INFO | recording the execution... +08:28:31 DEBUG| Using selector: EpollSelector +08:28:31 DEBUG| Registering <qemu.qmp.events.EventListener object at 0x7ff6584bae50>. +08:28:31 DEBUG| VM launch command: './qemu-system-ppc64 -display none -vga none -chardev socket,id=mon,fd=5 -mon chardev=mon,mode=control -machine powernv -chardev socket,id=console,fd=19 -serial chardev:console -icount shift=7,rr=record,rrfile=/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/replay.bin,rrsnapshot=init -net none -drive file=/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/disk.qcow2,if=none' +08:28:31 DEBUG| Transitioning from 'Runstate.IDLE' to 'Runstate.CONNECTING'. +08:28:31 DEBUG| Connecting with existing socket: fd=12, family=<AddressFamily.AF_UNIX: 1>, type=<SocketKind.SOCK_STREAM: 1> +08:28:31 DEBUG| Connected. +08:28:31 DEBUG| Awaiting greeting ... +08:28:31 DEBUG| <-- { + "QMP": { + "version": { + "qemu": { + "micro": 90, + "minor": 1, + "major": 8 + }, + "package": "v5.2.0-26508-gaf9264da80" + }, + "capabilities": [ + "oob" + ] + } +} +08:28:31 DEBUG| Negotiating capabilities ... +08:28:31 DEBUG| --> { + "execute": "qmp_capabilities", + "arguments": { + "enable": [ + "oob" + ] + } +} +08:28:31 DEBUG| <-- { + "return": {} +} +08:28:31 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'. +08:28:31 DEBUG| Opening console socket +08:28:31 DEBUG| --> { + "execute": "query-replay" +} +08:28:31 DEBUG| <-- { + "return": { + "icount": 5521801, + "mode": "record", + "filename": "/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/replay.bin" + } +} +08:28:31 DEBUG| --> { + "execute": "query-replay" +} +08:28:31 DEBUG| [ 0.230392217,5] OPAL v7.0 starting... +08:28:31 DEBUG| [ 0.230674939,7] initial console log level: memory 7, driver 5 +08:28:31 DEBUG| [ 0.231048494,6] CPU: P9 generation processor (max 4 threads/core) +08:28:31 DEBUG| [ 0.231412547,7] CPU: Boot CPU PIR is 0x0000 PVR is 0x004e1202 +08:28:31 DEBUG| [ 0.231857798,7] OPAL table +08:28:31 DEBUG| <-- { + "return": { + "icount": 5655658, + "mode": "record", + "filename": "/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/replay.bin" + } +} +08:28:31 DEBUG| Shutting down VM appliance; timeout=30 +08:28:31 DEBUG| Attempting graceful termination +08:28:31 DEBUG| Closing console socket +08:28:31 DEBUG| Politely asking QEMU to terminate +08:28:31 DEBUG| --> { + "execute": "quit" +} +08:28:31 DEBUG| <-- { + "return": {} +} +08:28:31 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 453159 + }, + "event": "SHUTDOWN", + "data": { + "guest": false, + "reason": "host-qmp-quit" + } +} +08:28:31 DEBUG| disconnect() called. +08:28:31 DEBUG| Transitioning from 'Runstate.RUNNING' to 'Runstate.DISCONNECTING'. +08:28:31 DEBUG| Scheduling disconnect. +08:28:31 DEBUG| Draining the outbound queue ... +08:28:31 DEBUG| Flushing the StreamWriter ... +08:28:31 DEBUG| Cancelling writer task. +08:28:31 DEBUG| Cancelling reader task. +08:28:31 DEBUG| Waiting for tasks to complete ... +08:28:31 DEBUG| Task.Writer: cancelled. +08:28:31 DEBUG| Task.Writer: exiting. +08:28:31 DEBUG| Task.Reader: cancelled. +08:28:31 DEBUG| Task.Reader: exiting. +08:28:31 DEBUG| Closing StreamWriter. +08:28:31 DEBUG| Waiting for StreamWriter to close ... +08:28:31 DEBUG| StreamWriter closed. +08:28:31 DEBUG| Disconnected. +08:28:31 DEBUG| QMP Disconnected. +08:28:31 DEBUG| Transitioning from 'Runstate.DISCONNECTING' to 'Runstate.IDLE'. +08:28:31 DEBUG| Waiting (timeout=30) for QEMU process (pid=1580) to terminate +08:28:31 DEBUG| Cleaning up after VM process +08:28:31 INFO | recorded log with 5655658+ steps +08:28:31 DEBUG| QEMUMachine "1dfa83ad-c638-4858-b96d-ec21870ab53a" created +08:28:31 DEBUG| QEMUMachine "1dfa83ad-c638-4858-b96d-ec21870ab53a" temp_dir: /builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/qemu-machine-i11yz6dd +08:28:31 DEBUG| QEMUMachine "1dfa83ad-c638-4858-b96d-ec21870ab53a" log_dir: /builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv +08:28:31 INFO | replaying the execution... +08:28:31 DEBUG| Registering <qemu.qmp.events.EventListener object at 0x7ff655d27700>. +08:28:31 DEBUG| VM launch command: './qemu-system-ppc64 -display none -vga none -chardev socket,id=mon,fd=5 -mon chardev=mon,mode=control -machine powernv -chardev socket,id=console,fd=19 -serial chardev:console -gdb tcp::21192 -S -icount shift=7,rr=replay,rrfile=/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/replay.bin,rrsnapshot=init -net none -drive file=/builds/thuth/qemu/build/tests/results/job-2023-11-21T08.18-1c1e081/test-results/tmp_dirvmnrd25o/79-tests_avocado_reverse_debugging.py_ReverseDebugging_ppc64.test_ppc64_powernv/disk.qcow2,if=none' +08:28:31 DEBUG| Transitioning from 'Runstate.IDLE' to 'Runstate.CONNECTING'. +08:28:31 DEBUG| Connecting with existing socket: fd=12, family=<AddressFamily.AF_UNIX: 1>, type=<SocketKind.SOCK_STREAM: 1> +08:28:31 DEBUG| Connected. +08:28:31 DEBUG| Awaiting greeting ... +08:28:31 DEBUG| <-- { + "QMP": { + "version": { + "qemu": { + "micro": 90, + "minor": 1, + "major": 8 + }, + "package": "v5.2.0-26508-gaf9264da80" + }, + "capabilities": [ + "oob" + ] + } +} +08:28:31 DEBUG| Negotiating capabilities ... +08:28:31 DEBUG| --> { + "execute": "qmp_capabilities", + "arguments": { + "enable": [ + "oob" + ] + } +} +08:28:31 DEBUG| <-- { + "return": {} +} +08:28:31 DEBUG| Transitioning from 'Runstate.CONNECTING' to 'Runstate.RUNNING'. +08:28:31 DEBUG| Opening console socket +08:28:31 INFO | connecting to gdbstub +08:28:31 INFO | stepping forward +08:28:31 INFO | saving position 10 +08:28:31 INFO | saving position 14 +08:28:31 INFO | saving position 40 +08:28:31 INFO | saving position 44 +08:28:31 INFO | saving position 3008 +08:28:31 INFO | saving position 300c +08:28:31 INFO | saving position 3010 +08:28:31 INFO | saving position 3014 +08:28:31 INFO | saving position 3018 +08:28:31 INFO | saving position 301c +08:28:31 INFO | stepping backward +08:28:31 INFO | found position 301c +08:28:31 INFO | found position 3018 +08:28:31 INFO | found position 3014 +08:28:31 INFO | found position 3010 +08:28:31 INFO | found position 300c +08:28:31 INFO | found position 3008 +08:28:31 INFO | found position 44 +08:28:31 INFO | found position 40 +08:28:32 INFO | found position 14 +08:28:32 INFO | found position 10 +08:28:32 INFO | stepping forward +08:28:32 INFO | found position 10 +08:28:32 INFO | found position 14 +08:28:32 INFO | found position 40 +08:28:32 INFO | found position 44 +08:28:32 INFO | found position 3008 +08:28:32 INFO | found position 300c +08:28:32 INFO | found position 3010 +08:28:32 INFO | found position 3014 +08:28:32 INFO | found position 3018 +08:28:32 INFO | found position 301c +08:28:32 INFO | setting breakpoints +08:28:32 INFO | continuing execution +08:28:32 DEBUG| --> { + "execute": "replay-break", + "arguments": { + "icount": 5655657 + } +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 630400 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 630738 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 630965 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 631155 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 631438 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 631653 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 631935 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 632127 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 632380 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 632593 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 632858 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 633051 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 633316 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 633517 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 633775 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 633973 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 634247 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 634437 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 634707 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 634910 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 681146 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 681795 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 722346 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 723103 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 764757 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 765468 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 806932 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 807686 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 849868 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 850664 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 892036 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 892734 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 934846 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 935520 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 976442 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555311, + "microseconds": 977155 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 29287 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 30093 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 74012 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 74271 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 74873 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 75471 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 75800 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 75987 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 76239 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 76423 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 76666 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 76861 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 77106 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 77321 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 77564 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 77760 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 77987 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 78176 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 78408 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 78598 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 78846 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 79033 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 79267 + }, + "event": "RESUME" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 79451 + }, + "event": "STOP" +} +08:28:32 DEBUG| <-- { + "return": {} +} +08:28:32 DEBUG| [ 0.230392217,5] OPAL v7.0 starting... +08:28:32 DEBUG| [ 0.230674939,7] initial console log level: memory 7, driver 5 +08:28:32 DEBUG| [ 0.231048494,6] CPU: P9 generation processor (max 4 threads/core) +08:28:32 DEBUG| [ +08:28:32 DEBUG| [ 0.231412547,7] CPU: Boot CPU PIR is 0x0000 PVR is 0x004e1202 +08:28:32 DEBUG| [ +08:28:32 ERROR| +08:28:32 ERROR| Reproduced traceback from: /builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/core/test.py:770 +08:28:32 ERROR| Traceback (most recent call last): +08:28:32 ERROR| File "/builds/thuth/qemu/build/tests/avocado/reverse_debugging.py", line 262, in test_ppc64_powernv +08:28:32 ERROR| self.reverse_debugging() +08:28:32 ERROR| File "/builds/thuth/qemu/build/tests/avocado/reverse_debugging.py", line 178, in reverse_debugging +08:28:32 ERROR| g.cmd(b'c') +08:28:32 ERROR| File "/builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/utils/gdb.py", line 783, in cmd +08:28:32 ERROR| response_payload = self.decode(result) +08:28:32 ERROR| File "/builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/utils/gdb.py", line 738, in decode +08:28:32 ERROR| raise InvalidPacketError +08:28:32 ERROR| avocado.utils.gdb.InvalidPacketError +08:28:32 ERROR| +08:28:32 DEBUG| Local variables: +08:28:32 DEBUG| -> self <class 'reverse_debugging.ReverseDebugging_ppc64'>: 79-tests/avocado/reverse_debugging.py:ReverseDebugging_ppc64.test_ppc64_powernv +08:28:32 DEBUG| Shutting down VM appliance; timeout=30 +08:28:32 DEBUG| Attempting graceful termination +08:28:32 DEBUG| Closing console socket +08:28:32 DEBUG| Politely asking QEMU to terminate +08:28:32 DEBUG| --> { + "execute": "quit" +} +08:28:32 DEBUG| <-- { + "timestamp": { + "seconds": 1700555312, + "microseconds": 86122 + }, + "event": "RESUME" +} +08:28:32 ERROR| Task.Reader: BrokenPipeError: [Errno 32] Broken pipe +08:28:32 DEBUG| Task.Reader: failure: + | Traceback (most recent call last): + | File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 870, in _bh_loop_forever + | await async_fn() + | File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 908, in _bh_recv_message + | msg = await self._recv() + | File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 1009, in _recv + | message = await self._do_recv() + | File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 402, in _do_recv + | msg_bytes = await self._readline() + | File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 973, in _readline + | msg_bytes = await self._reader.readline() + | File "/usr/lib64/python3.8/asyncio/streams.py", line 540, in readline + | line = await self.readuntil(sep) + | File "/usr/lib64/python3.8/asyncio/streams.py", line 632, in readuntil + | await self._wait_for_data('readuntil') + | File "/usr/lib64/python3.8/asyncio/streams.py", line 517, in _wait_for_data + | await self._waiter + | File "/usr/lib64/python3.8/asyncio/selector_events.py", line 910, in write + | n = self._sock.send(data) + | BrokenPipeError: [Errno 32] Broken pipe + +08:28:32 DEBUG| Transitioning from 'Runstate.RUNNING' to 'Runstate.DISCONNECTING'. +08:28:32 DEBUG| Scheduling disconnect. +08:28:32 DEBUG| Task.Reader: exiting. +08:28:32 DEBUG| Cancelling writer task. +08:28:32 DEBUG| Waiting for tasks to complete ... +08:28:32 DEBUG| Task.Writer: cancelled. +08:28:32 DEBUG| Task.Writer: exiting. +08:28:32 DEBUG| Waiting for StreamWriter to close ... +08:28:32 DEBUG| Discarding Exception from wait_closed: + | Traceback (most recent call last): + | File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 834, in _bh_close_stream + | await wait_closed(self._writer) + | File "/builds/thuth/qemu/python/qemu/qmp/util.py", line 130, in wait_closed + | await writer.wait_closed() + | File "/usr/lib64/python3.8/asyncio/streams.py", line 359, in wait_closed + | await self._protocol._get_close_waiter(self) + | File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 870, in _bh_loop_forever + | await async_fn() + | File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 908, in _bh_recv_message + | msg = await self._recv() + | File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 1009, in _recv + | message = await self._do_recv() + | File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 402, in _do_recv + | msg_bytes = await self._readline() + | File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 973, in _readline + | msg_bytes = await self._reader.readline() + | File "/usr/lib64/python3.8/asyncio/streams.py", line 540, in readline + | line = await self.readuntil(sep) + | File "/usr/lib64/python3.8/asyncio/streams.py", line 632, in readuntil + | await self._wait_for_data('readuntil') + | File "/usr/lib64/python3.8/asyncio/streams.py", line 517, in _wait_for_data + | await self._waiter + | File "/usr/lib64/python3.8/asyncio/selector_events.py", line 910, in write + | n = self._sock.send(data) + | BrokenPipeError: [Errno 32] Broken pipe + +08:28:32 DEBUG| StreamWriter closed. +08:28:32 DEBUG| Disconnected. +08:28:32 DEBUG| Cancelling pending executions +08:28:32 DEBUG| Cancelling execution 'None' +08:28:32 DEBUG| QMP Disconnected. +08:28:32 DEBUG| disconnect() called. +08:28:32 DEBUG| Transitioning from 'Runstate.DISCONNECTING' to 'Runstate.IDLE'. +08:28:32 DEBUG| Graceful shutdown failed +Traceback (most recent call last): + File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 574, in _soft_shutdown + self.qmp('quit') + File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 705, in qmp + ret = self._qmp.cmd_raw(cmd, args=qmp_args) + File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 208, in cmd_raw + return self.cmd_obj(qmp_cmd) + File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 186, in cmd_obj + self._sync( + File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 102, in _sync + return self._aloop.run_until_complete( + File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete + return future.result() + File "/usr/lib64/python3.8/asyncio/tasks.py", line 455, in wait_for + return await fut + File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 547, in _raw + return await self._execute(msg, assign_id=assign_id) + File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 496, in _execute + return await self._reply(exec_id) + File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 463, in _reply + raise result +qemu.qmp.qmp_client.ExecInterruptedError: Disconnected + +During handling of the above exception, another exception occurred: + +Traceback (most recent call last): + File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 605, in _do_shutdown + self._soft_shutdown(timeout) + File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 577, in _soft_shutdown + self._close_qmp_connection() + File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 495, in _close_qmp_connection + self._qmp.close() + File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 281, in close + self._sync( + File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 102, in _sync + return self._aloop.run_until_complete( + File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete + return future.result() + File "/usr/lib64/python3.8/asyncio/tasks.py", line 455, in wait_for + return await fut + File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 399, in disconnect + await self._wait_disconnect() + File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 719, in _wait_disconnect + await all_defined_tasks # Raise Exceptions from the bottom half. + File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 834, in _bh_close_stream + await wait_closed(self._writer) + File "/builds/thuth/qemu/python/qemu/qmp/util.py", line 130, in wait_closed + await writer.wait_closed() + File "/usr/lib64/python3.8/asyncio/streams.py", line 359, in wait_closed + await self._protocol._get_close_waiter(self) + File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 870, in _bh_loop_forever + await async_fn() + File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 908, in _bh_recv_message + msg = await self._recv() + File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 1009, in _recv + message = await self._do_recv() + File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 402, in _do_recv + msg_bytes = await self._readline() + File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 973, in _readline + msg_bytes = await self._reader.readline() + File "/usr/lib64/python3.8/asyncio/streams.py", line 540, in readline + line = await self.readuntil(sep) + File "/usr/lib64/python3.8/asyncio/streams.py", line 632, in readuntil + await self._wait_for_data('readuntil') + File "/usr/lib64/python3.8/asyncio/streams.py", line 517, in _wait_for_data + await self._waiter + File "/usr/lib64/python3.8/asyncio/selector_events.py", line 910, in write + n = self._sock.send(data) +BrokenPipeError: [Errno 32] Broken pipe +08:28:32 DEBUG| Falling back to hard shutdown +08:28:32 DEBUG| Performing hard shutdown +08:28:32 DEBUG| Cleaning up after VM process +08:28:32 ERROR| +08:28:32 ERROR| Reproduced traceback from: /builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/core/test.py:796 +08:28:32 ERROR| Traceback (most recent call last): +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 574, in _soft_shutdown +08:28:32 ERROR| self.qmp('quit') +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 705, in qmp +08:28:32 ERROR| ret = self._qmp.cmd_raw(cmd, args=qmp_args) +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 208, in cmd_raw +08:28:32 ERROR| return self.cmd_obj(qmp_cmd) +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 186, in cmd_obj +08:28:32 ERROR| self._sync( +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 102, in _sync +08:28:32 ERROR| return self._aloop.run_until_complete( +08:28:32 ERROR| File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete +08:28:32 ERROR| return future.result() +08:28:32 ERROR| File "/usr/lib64/python3.8/asyncio/tasks.py", line 455, in wait_for +08:28:32 ERROR| return await fut +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 547, in _raw +08:28:32 ERROR| return await self._execute(msg, assign_id=assign_id) +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 496, in _execute +08:28:32 ERROR| return await self._reply(exec_id) +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 463, in _reply +08:28:32 ERROR| raise result +08:28:32 ERROR| qemu.qmp.qmp_client.ExecInterruptedError: Disconnected +08:28:32 ERROR| +08:28:32 ERROR| During handling of the above exception, another exception occurred: +08:28:32 ERROR| +08:28:32 ERROR| Traceback (most recent call last): +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 605, in _do_shutdown +08:28:32 ERROR| self._soft_shutdown(timeout) +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 577, in _soft_shutdown +08:28:32 ERROR| self._close_qmp_connection() +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 495, in _close_qmp_connection +08:28:32 ERROR| self._qmp.close() +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 281, in close +08:28:32 ERROR| self._sync( +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/legacy.py", line 102, in _sync +08:28:32 ERROR| return self._aloop.run_until_complete( +08:28:32 ERROR| File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete +08:28:32 ERROR| return future.result() +08:28:32 ERROR| File "/usr/lib64/python3.8/asyncio/tasks.py", line 455, in wait_for +08:28:32 ERROR| return await fut +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 399, in disconnect +08:28:32 ERROR| await self._wait_disconnect() +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 719, in _wait_disconnect +08:28:32 ERROR| await all_defined_tasks # Raise Exceptions from the bottom half. +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 834, in _bh_close_stream +08:28:32 ERROR| await wait_closed(self._writer) +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/util.py", line 130, in wait_closed +08:28:32 ERROR| await writer.wait_closed() +08:28:32 ERROR| File "/usr/lib64/python3.8/asyncio/streams.py", line 359, in wait_closed +08:28:32 ERROR| await self._protocol._get_close_waiter(self) +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 870, in _bh_loop_forever +08:28:32 ERROR| await async_fn() +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 908, in _bh_recv_message +08:28:32 ERROR| msg = await self._recv() +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 1009, in _recv +08:28:32 ERROR| message = await self._do_recv() +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/qmp_client.py", line 402, in _do_recv +08:28:32 ERROR| msg_bytes = await self._readline() +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/qmp/protocol.py", line 973, in _readline +08:28:32 ERROR| msg_bytes = await self._reader.readline() +08:28:32 ERROR| File "/usr/lib64/python3.8/asyncio/streams.py", line 540, in readline +08:28:32 ERROR| line = await self.readuntil(sep) +08:28:32 ERROR| File "/usr/lib64/python3.8/asyncio/streams.py", line 632, in readuntil +08:28:32 ERROR| await self._wait_for_data('readuntil') +08:28:32 ERROR| File "/usr/lib64/python3.8/asyncio/streams.py", line 517, in _wait_for_data +08:28:32 ERROR| await self._waiter +08:28:32 ERROR| File "/usr/lib64/python3.8/asyncio/selector_events.py", line 910, in write +08:28:32 ERROR| n = self._sock.send(data) +08:28:32 ERROR| BrokenPipeError: [Errno 32] Broken pipe +08:28:32 ERROR| +08:28:32 ERROR| The above exception was the direct cause of the following exception: +08:28:32 ERROR| +08:28:32 ERROR| Traceback (most recent call last): +08:28:32 ERROR| File "/builds/thuth/qemu/build/tests/avocado/avocado_qemu/__init__.py", line 384, in tearDown +08:28:32 ERROR| vm.shutdown() +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 642, in shutdown +08:28:32 ERROR| self._do_shutdown(timeout) +08:28:32 ERROR| File "/builds/thuth/qemu/python/qemu/machine/machine.py", line 612, in _do_shutdown +08:28:32 ERROR| raise AbnormalShutdown("Could not perform graceful shutdown") \ +08:28:32 ERROR| qemu.machine.machine.AbnormalShutdown: Could not perform graceful shutdown +08:28:32 ERROR| +08:28:32 DEBUG| DATA (filename=output.expected) => NOT FOUND (data sources: variant, test, file) +08:28:32 DEBUG| DATA (filename=stdout.expected) => NOT FOUND (data sources: variant, test, file) +08:28:32 DEBUG| DATA (filename=stderr.expected) => NOT FOUND (data sources: variant, test, file) +08:28:32 ERROR| Traceback (most recent call last): + +08:28:32 ERROR| File "/builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/core/test.py", line 858, in _run_avocado + raise test_exception + +08:28:32 ERROR| File "/builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/core/test.py", line 765, in _run_avocado + testMethod() + +08:28:32 ERROR| File "/builds/thuth/qemu/build/tests/avocado/reverse_debugging.py", line 262, in test_ppc64_powernv + self.reverse_debugging() + +08:28:32 ERROR| File "/builds/thuth/qemu/build/tests/avocado/reverse_debugging.py", line 178, in reverse_debugging + g.cmd(b'c') + +08:28:32 ERROR| File "/builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/utils/gdb.py", line 783, in cmd + response_payload = self.decode(result) + +08:28:32 ERROR| File "/builds/thuth/qemu/build/pyvenv/lib64/python3.8/site-packages/avocado/utils/gdb.py", line 738, in decode + raise InvalidPacketError + +08:28:32 ERROR| avocado.utils.gdb.InvalidPacketError + +08:28:32 ERROR| ERROR 79-tests/avocado/reverse_debugging.py:ReverseDebugging_ppc64.test_ppc64_powernv -> InvalidPacketError: +08:28:32 INFO | +``` diff --git a/results/classifier/gemma3:12b/debug/1993 b/results/classifier/gemma3:12b/debug/1993 new file mode 100644 index 000000000..60cd77f5e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/1993 @@ -0,0 +1,51 @@ + +test-hmp fails on aarch64 target when CFI is enabled +Description of problem: +QEMU crashes during test-hmp when CFI is enabled +Steps to reproduce: +1. ../qemu/configure --cc=clang --cxx=clang++ --enable-cfi --enable-cfi-debug --enable-safe-stack --disable-slirp --target-list=aarch64-softmmu --disable-docs +2. make -j$(nproc) +3. V=2 QTEST_QEMU_BINARY=./qemu-system-aarch64 tests/qtest/test-hmp --verbose +Additional information: +The error messages look like this: +``` + info qtree +UndefinedBehaviorSanitizer:DEADLYSIGNAL +==677987==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address (pc 0x55fec2a3b7ce bp 0x7feef35ff970 sp 0x7fffbc8acd20 T677987) +==677987==The signal is caused by a READ memory access. +==677987==Hint: this fault was caused by a dereference of a high value address (see register values below). Disassemble the provided pc to learn which register was used. + #0 0x55fec2a3b7ce in start_list.83665.cfi /tmp/qemu-cfi/../../home/thuth/devel/qemu/qapi/string-output-visitor.c:291:18 + #1 0x55fec2a34dbe in visit_start_list /tmp/qemu-cfi/../../home/thuth/devel/qemu/qapi/qapi-visit-core.c:80:10 + #2 0x55fec27dcb58 in get_prop_array.cfi /tmp/qemu-cfi/../../home/thuth/devel/qemu/hw/core/qdev-properties.c:698:10 + #3 0x55fec27e7173 in object_property_get /tmp/qemu-cfi/../../home/thuth/devel/qemu/qom/object.c:1415:5 + #4 0x55fec27e87a4 in object_property_print /tmp/qemu-cfi/../../home/thuth/devel/qemu/qom/object.c:1692:10 + #5 0x55fec224dd72 in qdev_print_props /tmp/qemu-cfi/../../home/thuth/devel/qemu/system/qdev-monitor.c:761:21 + #6 0x55fec224dd72 in qdev_print /tmp/qemu-cfi/../../home/thuth/devel/qemu/system/qdev-monitor.c:813:9 + #7 0x55fec224dd72 in qbus_print /tmp/qemu-cfi/../../home/thuth/devel/qemu/system/qdev-monitor.c:831:9 + #8 0x55fec22bd945 in handle_hmp_command_exec /tmp/qemu-cfi/../../home/thuth/devel/qemu/monitor/hmp.c:1106:9 + #9 0x55fec22bcfeb in handle_hmp_command /tmp/qemu-cfi/../../home/thuth/devel/qemu/monitor/hmp.c:1158:9 + #10 0x55fec22c020e in qmp_human_monitor_command /tmp/qemu-cfi/../../home/thuth/devel/qemu/monitor/qmp-cmds.c:182:5 + #11 0x55fec29cfe0b in qmp_marshal_human_monitor_command.cfi /tmp/qemu-cfi/qapi/qapi-commands-misc.c:347:14 + #12 0x55fec2a3c470 in do_qmp_dispatch_bh.cfi /tmp/qemu-cfi/../../home/thuth/devel/qemu/qapi/qmp-dispatch.c:128:5 + #13 0x55fec2a63fc4 in aio_bh_call /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/async.c:169:5 + #14 0x55fec2a6418f in aio_bh_poll /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/async.c:216:13 + #15 0x55fec2a49deb in aio_dispatch /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/aio-posix.c:423:5 + #16 0x55fec2a64ffa in aio_ctx_dispatch.cfi /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/async.c:358:5 + #17 0x7feef8d6ae5b (/lib64/libglib-2.0.so.0+0x5be5b) (BuildId: c5377a60d8282e2a61a4af1201dc10c9666139c2) + #18 0x7feef8d6b124 in g_main_context_dispatch (/lib64/libglib-2.0.so.0+0x5c124) (BuildId: c5377a60d8282e2a61a4af1201dc10c9666139c2) + #19 0x55fec2a6656b in glib_pollfds_poll /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/main-loop.c:290:9 + #20 0x55fec2a6656b in os_host_main_loop_wait /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/main-loop.c:313:5 + #21 0x55fec2a6656b in main_loop_wait /tmp/qemu-cfi/../../home/thuth/devel/qemu/util/main-loop.c:592:11 + #22 0x55fec22553e6 in qemu_main_loop /tmp/qemu-cfi/../../home/thuth/devel/qemu/system/runstate.c:782:9 + #23 0x55fec27da3f5 in qemu_default_main.cfi /tmp/qemu-cfi/../../home/thuth/devel/qemu/system/main.c:37:14 + #24 0x7feef7aff149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: 651b2bed7ecaf18098a63b8f10299821749766e6) + #25 0x7feef7aff20a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2820a) (BuildId: 651b2bed7ecaf18098a63b8f10299821749766e6) + #26 0x55fec1e865b4 in _start (/tmp/qemu-cfi/qemu-system-aarch64+0x5435b4) (BuildId: c8a2f51d83ddef5c97f11783d94381f60c82c2ac) + +UndefinedBehaviorSanitizer can not provide additional info. +SUMMARY: UndefinedBehaviorSanitizer: SEGV /tmp/qemu-cfi/../../home/thuth/devel/qemu/qapi/string-output-visitor.c:291:18 in start_list.83665.cfi +==677987==ABORTING +Broken pipe +../../home/thuth/devel/qemu/tests/qtest/libqtest.c:195: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0) +Aborted (core dumped) +``` diff --git a/results/classifier/gemma3:12b/debug/2035 b/results/classifier/gemma3:12b/debug/2035 new file mode 100644 index 000000000..9009556dd --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2035 @@ -0,0 +1,55 @@ + +TCG Plugin exit callback not executing +Description of problem: +I cannot get the plugin exit callback to register/execute. I should see "Goodbye from plugin" but dont. I have also tried using `qemu_plugin_outs` without success. + +**Update: If I make my test binary an infinite loop and kill it with CTRL-C, then the callback is called as expected. Am I just using it wrong?** +Steps to reproduce: +1. Configured QEMU with `--target-list=riscv32-linux-user,riscv64-linux-user --enable-plugins --disable-system` +2. Compiled plugin with +``` +gcc -I./qemu/include/qemu `pkg-config --libs glib-2.0` -O0 -fvisibility=hidden -Wall -shared -fPIC `pkg-config --cflags glib-2.0` +``` +3. Compiled test binary (just a hello world) with `riscv64-unknown-elf-gcc test_qemu.c -o test_qemu` +4. Ran ./qemu/build/qemu-riscv64 -plugin ./test_plugin.so -d plugin ./test_qemu +Additional information: +test_plugin.c +``` +#include <inttypes.h> +#include <assert.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <stdio.h> +#include <qemu-plugin.h> + +QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION; + +static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb) +{ + int n_insns = qemu_plugin_tb_n_insns(tb); + printf("> New TB of size %d\n", n_insns); + + for (int i = 0; i < n_insns; i++) { + struct qemu_plugin_insn * insn = qemu_plugin_tb_get_insn(tb, i); + char * disassembly = qemu_plugin_insn_disas(insn); + printf(" > Instruciton: %s\n", disassembly); + } +} + +static void plugin_exit(qemu_plugin_id_t id, void *p) +{ + printf("> Goodbye from plugin. %d\n", id); +} + +QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id, + const qemu_info_t *info, + int argc, char **argv) +{ + printf("> Hello From Plugin!\n"); + qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans); + qemu_plugin_register_atexit_cb(id, plugin_exit, NULL); + printf("> Everything was registered\n"); + return 0; +} +``` diff --git a/results/classifier/gemma3:12b/debug/2038 b/results/classifier/gemma3:12b/debug/2038 new file mode 100644 index 000000000..8de2ee6b7 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2038 @@ -0,0 +1,17 @@ + +simpletrace.py does nothing, and syntax error when called from bash script +Description of problem: +The simpletrace python script appears to do nothing when I run it as above. + +It appears to run (but do nothing) when called from my terminal but there is also a syntax error when I run it from the bash script above. + +``` +SyntaxError: invalid syntax + File "<fstring>", line 1 + (pid=) + ^ +``` + +I think this syntax error is caused by the line `print(f'{event.name} {delta_ns / 1000:0.3f} {pid=} ' + ' '.join(fields))` +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/2059 b/results/classifier/gemma3:12b/debug/2059 new file mode 100644 index 000000000..6e425a557 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2059 @@ -0,0 +1,24 @@ + +Solaris 2.6.5 panic when trying to debug a binary with Sun Workshop V5n1, or V6n1 debugger +Description of problem: +Following [this guide](https://www.gekk.info/articles/solaris26.htm), and similarly to issue #1166, the guest panics when one tries to debug a binary with the debugger provided in [Sun Workshop V5n1](https://archive.org/details/sunworkshopforsolaris2vol5num1_704546810revb), and in [Sun Workshop v6n1](https://archive.org/details/devpro_v6n1) as well. +The Sun Workshop is EOL, available at the archive, with free non-expiring demo licenses [made available](https://archive.org/details/suncomp-lic) by Sun before the Oracle acquisition. +The guest was patched with the latest available patches included [in this cluster](https://archive.org/details/sun26gnu). +The following information was collected when debugging bunzip2, but any binary panics the guest. +``` +panic: Non-parity synchronous error: ctx=54 va=ef7cbc44 pa=e0a8c44 +syncing filesystems... 15 done +NOTICE: zs3:ring buffer overflow +``` +Steps to reproduce: +1. Start the Sun Workshop (SUNWspro/bin/workshop), go to the Debugger in the menu +2. Debug/New Program, load any binary, place a breakpoint in main or wherever +3. Execute, guest kernel panic +Additional information: +This happens with the Fujitsu MB86904 specified as CPU, and without specifying a cpu, using the default for the SS-5. + + + +Explicitly setting the TI MicroSparc I and setting memory to 32M seems to start the debugger, the guest still panics, but a bit further down the line + + diff --git a/results/classifier/gemma3:12b/debug/2072564 b/results/classifier/gemma3:12b/debug/2072564 new file mode 100644 index 000000000..80539baae --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2072564 @@ -0,0 +1,46 @@ + +qemu-aarch64-static segfaults running ldconfig.real (amd64 host) + +This affects the qemu-user-static 1:8.2.2+ds-0ubuntu1 package on Ubuntu 24.04, running on a amd64 host. + +When running docker containers with Ubuntu 22.04 in them, emulating arm64 with qemu-aarch64-static, invocations of ldconfig (actually ldconfig.real) segfault. For example: + +$ docker run -ti --platform linux/arm64/v8 ubuntu:22.04 +root@8861ff640a1c:/# /sbin/ldconfig.real +Segmentation fault + +If you copy the ldconfig.real binary to the host, and run it directly via qemu-aarch64-static: + +$ gdb --args qemu-aarch64-static ./ldconfig.real +GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git +Copyright (C) 2024 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from qemu-aarch64-static... +Reading symbols from /home/dim/.cache/debuginfod_client/86579812b213be0964189499f62f176bea817bf2/debuginfo... +(gdb) r +Starting program: /usr/bin/qemu-aarch64-static ./ldconfig.real +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +[New Thread 0x7ffff76006c0 (LWP 28378)] + +Thread 1 "qemu-aarch64-st" received signal SIGSEGV, Segmentation fault. +0x00007fffe801645b in ?? () +(gdb) disassemble +No function contains program counter for selected frame. + +It looks like this is a known qemu regression after v8.1.1: +https://gitlab.com/qemu-project/qemu/-/issues/1913 + +Downgrading the package to qemu-user-static_8.0.4+dfsg-1ubuntu3_amd64.deb fixes the segfault. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/208 b/results/classifier/gemma3:12b/debug/208 new file mode 100644 index 000000000..6e35ad30c --- /dev/null +++ b/results/classifier/gemma3:12b/debug/208 @@ -0,0 +1,2 @@ + +Write a new, asynchronous qmp-shell TUI diff --git a/results/classifier/gemma3:12b/debug/2104 b/results/classifier/gemma3:12b/debug/2104 new file mode 100644 index 000000000..837b4cc42 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2104 @@ -0,0 +1,2 @@ + +source code of function trace_memory_region_ops_write() diff --git a/results/classifier/gemma3:12b/debug/2105 b/results/classifier/gemma3:12b/debug/2105 new file mode 100644 index 000000000..4e651707d --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2105 @@ -0,0 +1,2 @@ + +memory trace not logging every memory write operation diff --git a/results/classifier/gemma3:12b/debug/2119 b/results/classifier/gemma3:12b/debug/2119 new file mode 100644 index 000000000..43eac92e6 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2119 @@ -0,0 +1,2 @@ + +target/riscv/gdbstub.c：The V registers in gdb debugging mode can only be accessed when the single-letter V is enabled diff --git a/results/classifier/gemma3:12b/debug/213 b/results/classifier/gemma3:12b/debug/213 new file mode 100644 index 000000000..96be28d58 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/213 @@ -0,0 +1,2 @@ + +memory writes via gdb don't work for memory mapped hardware diff --git a/results/classifier/gemma3:12b/debug/2130 b/results/classifier/gemma3:12b/debug/2130 new file mode 100644 index 000000000..ad8386681 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2130 @@ -0,0 +1,2 @@ + +latest code missing "singlestep" diff --git a/results/classifier/gemma3:12b/debug/2144 b/results/classifier/gemma3:12b/debug/2144 new file mode 100644 index 000000000..21eeaa1ad --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2144 @@ -0,0 +1,23 @@ + +macOS build fails when using --enable-debug +Description of problem: +the build fails because a symbol can't be found: + +``` +ld: Undefined symbols: + _lasi_82596_init, referenced from: + _machine_HP_common_init_tail in hw_hppa_machine.c.o +``` +Steps to reproduce: +1. on macOS 14.3 in build folder +2. ../configure --enable-debug +3. make -j12 +Additional information: +the default build with + +``` +../configure +make -j12 +``` + +succeeds normally. diff --git a/results/classifier/gemma3:12b/debug/2152 b/results/classifier/gemma3:12b/debug/2152 new file mode 100644 index 000000000..ed39bb236 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2152 @@ -0,0 +1,2 @@ + +TCG plugin to keep track what byte is load/store into memory diff --git a/results/classifier/gemma3:12b/debug/2159 b/results/classifier/gemma3:12b/debug/2159 new file mode 100644 index 000000000..1e5b85798 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2159 @@ -0,0 +1,178 @@ + +qemu-system-x86_64 crashes in temp_load (tcg) on i686 host +Description of problem: +qemu crashes early +Steps to reproduce: +1. compile qemu git (commit commit 5d1fc614413b10dd94858b07a1b2e26b1aa0296c (origin/master, origin/HEAD) +) with line +../configure --prefix=/usr --enable-virglrenderer --libdir=lib --audio-drv-list=alsa,oss --enable-opengl --extra-cflags="-I/usr/X11R7/include -O2 -march=i686 -mtune=native -m32 -Wno-maybe-uninitialized -Wno-nested-externs -Wno-implicit-function-declaration" --disable-werror + +2. setarch i686 ninja (kernel is x86_64 on host) +3. try to boot 64-bit x86 Salix/Slackel (Slackware live images) +Additional information: +``` + gdb x86_64-softmmu/qemu-system-x86_64 +GNU gdb (GDB) 11.2 +Copyright (C) 2022 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "i586-slackware-linux". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from x86_64-softmmu/qemu-system-x86_64... +warning: File "/dev/shm/qemu/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". +To enable execution of this file add + add-auto-load-safe-path /dev/shm/qemu/.gdbinit +line to your configuration file "/root/.config/gdb/gdbinit". +To completely disable this security protection add + set auto-load safe-path / +line to your configuration file "/root/.config/gdb/gdbinit". +For more information about this security protection see the +--Type <RET> for more, q to quit, c to continue without paging-- +"Auto-loading safe path" section in the GDB manual. E.g., run from the shell: + info "(gdb)Auto-loading safe path" +(gdb) r -m 1000 -cdrom /home/guest/ISO/sla +slackellive64-openbox-7.7.1.iso slackware-8.0-install-d1.iso +(gdb) r -m 1000 -cdrom /home/guest/ISO/slackellive64-openbox-7.7.1.iso +Starting program: /dev/shm/qemu/build/x86_64-softmmu/qemu-system-x86_64 -m 1000 -cdrom /home/guest/ISO/slackellive64-openbox-7.7.1.iso +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/libthread_db.so.1". +[New Thread 0xf3e79b00 (LWP 27354)] +[New Thread 0xf2f09b00 (LWP 27355)] +[New Thread 0xb1917b00 (LWP 27356)] +[New Thread 0xaf60cb00 (LWP 27357)] +[Thread 0xaf60cb00 (LWP 27357) exited] +[New Thread 0xaf60cb00 (LWP 27358)] +[New Thread 0xaec86b00 (LWP 27359)] +[Thread 0xaf60cb00 (LWP 27358) exited] +[Thread 0xaec86b00 (LWP 27359) exited] +[New Thread 0xaec86b00 (LWP 27360)] +[New Thread 0xaf60cb00 (LWP 27361)] +[Thread 0xaec86b00 (LWP 27360) exited] +[Thread 0xaf60cb00 (LWP 27361) exited] +[Thread 0xf2f09b00 (LWP 27355) exited] + +Thread 4 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0xb1917b00 (LWP 27356)] +0x56d08a95 in temp_load (s=0xb1000610, ts=ts@entry=0xb1001f40, desired_regs=<optimized out>, allocated_regs=2097200, preferred_regs=0) at ../tcg/tcg.c:4441 +4441 tcg_out_ld(s, ts->type, reg, ts->mem_base->reg, ts->mem_offset); +(gdb) bt full +#0 0x56d08a95 in temp_load + (s=0xb1000610, ts=ts@entry=0xb1001f40, desired_regs=<optimized out>, allocated_regs=2097200, preferred_regs=0) at ../tcg/tcg.c:4441 + reg = TCG_REG_ECX + __func__ = "temp_load" +#1 0x56d0fe23 in tcg_reg_alloc_op (op=<optimized out>, s=<optimized out>) + at ../tcg/tcg.c:4881 + i_required_regs = <optimized out> + copyto_new_reg = false + ts2 = <optimized out> + i1 = <optimized out> + i_preferred_regs = <optimized out> + allocate_new_reg = <optimized out> + i2 = <optimized out> + i = 0 + new_args = + {1, 5, 2852, 0, 64, 0, 0, 1467284236, 4149882880, 2829350448, 1, 1456305553, 4149882880, 2969568784, 2969568920, 2969568944} + arg_life = <optimized out> + i_allocated_regs = <optimized out> + nb_oargs = <optimized out> + arg = <optimized out> + const_args = +--Type <RET> for more, q to quit, c to continue without paging-- + {0, 0, 0, 0, 1, 1, 1467284236, -1315870200, 1487331864, -1069806704, 0, 1467284236, 1456520351, 1489883472, 2, -1325347776} + k = <optimized out> + arg_ct = <optimized out> + o_allocated_regs = <optimized out> + nb_iargs = <optimized out> + reg = <optimized out> + ts = 0xb1001f40 + op_cond = <optimized out> + opc = <optimized out> + i = <optimized out> + start_words = <optimized out> + num_insns = <optimized out> + op = <optimized out> + __PRETTY_FUNCTION__ = "tcg_gen_code" +#2 tcg_gen_code + (s=<optimized out>, tb=<optimized out>, pc_start=<optimized out>) + at ../tcg/tcg.c:6216 + opc = <optimized out> + i = <optimized out> + start_words = <optimized out> + num_insns = <optimized out> + op = <optimized out> +--Type <RET> for more, q to quit, c to continue without paging-- + __PRETTY_FUNCTION__ = "tcg_gen_code" +#3 0x56af0118 in setjmp_gen_code + (env=env@entry=0x57afab90, tb=tb@entry=0xf0b7d580 <code_gen_buffer+8389982>, pc=18446744072243800976, host_pc=0xc03c0b90, max_insns=0xb1916acc, ti=<optimized out>) at ../accel/tcg/translate-all.c:284 + ret = <optimized out> + __PRETTY_FUNCTION__ = "setjmp_gen_code" +#4 0x56af06e2 in tb_gen_code + (cpu=0x57af8860, pc=18446744072243800976, cs_base=0, flags=4244144, cflags=<optimized out>) at ../accel/tcg/translate-all.c:359 + env = 0x57afab90 + tb = 0xf0b7d580 <code_gen_buffer+8389982> + existing_tb = <optimized out> + phys_pc = 245525392 + phys_p2 = <optimized out> + gen_code_buf = 0xf0b7d600 <code_gen_buffer+8390110> "‹]ш…Ы\017Њр" + gen_code_size = <optimized out> + search_size = <optimized out> + max_insns = 64 + host_pc = 0xc03c0b90 + __PRETTY_FUNCTION__ = "tb_gen_code" + __func__ = "tb_gen_code" +#5 0x56ae75bd in cpu_exec_loop +--Type <RET> for more, q to quit, c to continue without paging-- + (cpu=cpu@entry=0x57af8860, sc=sc@entry=0xb1916c24) + at ../accel/tcg/cpu-exec.c:982 + jc = <optimized out> + h = <optimized out> + tb = 0x0 + flags = <optimized out> + cflags = 4278321152 + pc = <optimized out> + cs_base = <optimized out> + last_tb = <optimized out> + tb_exit = 0 + ret = <optimized out> +#6 0x56ae7a70 in cpu_exec_setjmp + (cpu=cpu@entry=0x57af8860, sc=sc@entry=0xb1916c24) + at ../accel/tcg/cpu-exec.c:1028 +#7 0x56ae83a8 in cpu_exec (cpu=<optimized out>) + at ../accel/tcg/cpu-exec.c:1054 + ret = <optimized out> + sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = 0} + _rcu_read_auto = 0x1 +#8 0x56b0ff5e in tcg_cpu_exec (cpu=0x57af8860) + at ../accel/tcg/tcg-accel-ops.c:76 + ret = <optimized out> +--Type <RET> for more, q to quit, c to continue without paging-- + __PRETTY_FUNCTION__ = "tcg_cpu_exec" +#9 0x56b10a47 in rr_cpu_thread_fn (arg=<optimized out>) + at ../accel/tcg/tcg-accel-ops-rr.c:261 + r = <optimized out> + cpu_budget = <optimized out> + force_rcu = + {notify = 0x56b106e0 <rr_force_rcu>, node = {le_next = 0x0, le_prev = 0xb19179b0}} + cpu = 0x57af8860 + __PRETTY_FUNCTION__ = "rr_cpu_thread_fn" +#10 0x56cc77e5 in qemu_thread_start (args=0x57b51ce0) + at ../util/qemu-thread-posix.c:541 + __cancel_buf = + {__cancel_jmp_buf = {{__cancel_jmp_buf = {1467284236, 1471487200, 1471152128, -1315869272, 1617656260, -631423478}, __mask_was_saved = 0}}, __pad = {0xb1916d64, 0x0, 0x0, 0x0}} + __cancel_routine = 0x56cc7840 <qemu_thread_atexit_notify> + __not_first_call = <optimized out> + start_routine = 0x56b10818 <rr_cpu_thread_fn> + arg = 0x57af8860 + r = <optimized out> +#11 0xf63d5328 in start_thread () at /lib/libpthread.so.0 +#12 0xf604ef06 in clone () at /lib/libc.so.6 +``` diff --git a/results/classifier/gemma3:12b/debug/2202 b/results/classifier/gemma3:12b/debug/2202 new file mode 100644 index 000000000..c6ab73c0e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2202 @@ -0,0 +1,34 @@ + +Crash in contrib/elf2dmp +Description of problem: +The elf2dmp program crash. +``` +$ ./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null +Using Linux mmap +[1] 994585 segmentation fault ./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null +``` +Steps to reproduce: +1. build the qemu project following standard steps +2. navigate to the `build` directory and run `./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null` + +The [crash_1](/uploads/d0890c0f8873b8264c417b0f98ee83a4/crash_1) file. +Additional information: +Run in GDB. +``` +$ gdb ./contrib/elf2dmp/elf2dmp +... +(gdb) set args ./crash_1 /dev/null +(gdb) r +Starting program: /data/share/qemu_latest/build/contrib/elf2dmp/elf2dmp ./crash_1 /dev/null +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +Using Linux mmap + +Program received signal SIGSEGV, Segmentation fault. +init_states (qe=0x7fffffff83f0) at ../contrib/elf2dmp/qemu_elf.c:66 +66 Elf64_Nhdr *start = (void *)((uint8_t *)qe->map + phdr[0].p_offset); +(gdb) bt +#0 init_states (qe=0x7fffffff83f0) at ../contrib/elf2dmp/qemu_elf.c:66 +#1 QEMU_Elf_init (qe=qe@entry=0x7fffffff83f0, filename=<optimized out>) at ../contrib/elf2dmp/qemu_elf.c:235 +#2 0x0000555555555508 in main (argc=<optimized out>, argv=0x7fffffffdb58) at ../contrib/elf2dmp/main.c:538 +``` diff --git a/results/classifier/gemma3:12b/debug/2207 b/results/classifier/gemma3:12b/debug/2207 new file mode 100644 index 000000000..e516c37f6 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2207 @@ -0,0 +1,12 @@ + +WerFault.exe – Application Error. The memory could not be read in Win7 i386 +Description of problem: +WerFault Application Errors always occur when I open IE or even control panel. It's OK on QEMU 7.2 & 8.0 version according to my debug experience about qemu-system-i386 flavor in the last few months. +Steps to reproduce: +1. pulling _tag: v8.2.0_ code +2. emulating Windows 7 OS on aarch64 Host with TCG acceleration mechanism +3. just opening IE for maybe two or three times after the virtual machine has started +Additional information: +The error is displayed by Chinese. It says _WerFault.exe – Application Error. The instruction at 0x779f77b2 referenced memory at 0x6d0f6d20. The memory could not be read._ in English + + diff --git a/results/classifier/gemma3:12b/debug/2208 b/results/classifier/gemma3:12b/debug/2208 new file mode 100644 index 000000000..e04a11636 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2208 @@ -0,0 +1,89 @@ + +PC is not updated for each instruction in TCG plugins +Description of problem: +I have checkout the `master` branch (the latest available commit on my machine is *7d4e29ef80*) to test the new functions that allow plugins to read registers. See https://gitlab.com/qemu-project/qemu/-/issues/1706 that has been closed last Friday. + +I am using a simple hello-world binary for ARM for my tests: + +```bash +% ./qemu-aarch64 hello-world.out +Hello World! +``` + +I run this binary with the *execlog* plugin enabled, and with the `-one-insn-per-tb` option: + +```bash +% ./qemu-aarch64 -d plugin -plugin ./contrib/plugins/libexeclog.so,reg=pc -one-insn-per-tb hello-world.out +``` + +Here is the end of the execution: + +```raw +0, 0x40e470, 0x54000040, "b.eq #0x40e478", pc -> 0x00000000000040e474 +0, 0x40e474, 0xd65f03c0, "ret ", pc -> 0x00000000000040d38c +0, 0x40d38c, 0xf945fab5, "ldr x21, [x21, #0xbf0]", load, 0x00490bf0, pc -> 0x00000000000040d390 +0, 0x40d390, 0xf9404fe0, "ldr x0, [sp, #0x98]", load, 0x7f635a9e7f28, pc -> 0x00000000000040d394 +0, 0x40d394, 0xf94002a1, "ldr x1, [x21]", load, 0x0048f9e8, pc -> 0x00000000000040d398 +0, 0x40d398, 0xeb010000, "subs x0, x0, x1", pc -> 0x00000000000040d39c +0, 0x40d39c, 0xd2800001, "movz x1, #0", pc -> 0x00000000000040d3a0 +0, 0x40d3a0, 0x540006e1, "b.ne #0x40d47c", pc -> 0x00000000000040d3a4 +0, 0x40d3a4, 0x2a1903e0, "mov w0, w25", pc -> 0x00000000000040d3a8 +0, 0x40d3a8, 0xa94153f3, "ldp x19, x20, [sp, #0x10]", load, 0x7f635a9e7ea0, pc -> 0x00000000000040d3ac +0, 0x40d3ac, 0xa9425bf5, "ldp x21, x22, [sp, #0x20]", load, 0x7f635a9e7eb0, pc -> 0x00000000000040d3b0 +0, 0x40d3b0, 0xa94363f7, "ldp x23, x24, [sp, #0x30]", load, 0x7f635a9e7ec0, pc -> 0x00000000000040d3b4 +0, 0x40d3b4, 0xa9446bf9, "ldp x25, x26, [sp, #0x40]", load, 0x7f635a9e7ed0, pc -> 0x00000000000040d3b8 +0, 0x40d3b8, 0xa8ca7bfd, "ldp x29, x30, [sp], #0xa0", load, 0x7f635a9e7e90, pc -> 0x00000000000040d3bc +0, 0x40d3bc, 0xd65f03c0, "ret ", pc -> 0x000000000000405d80 +0, 0x405d80, 0xeb13029f, "cmp x20, x19", pc -> 0x000000000000405d84 +0, 0x405d84, 0x91000694, "add x20, x20, #1", pc -> 0x000000000000405d88 +0, 0x405d88, 0x54ffff81, "b.ne #0x405d78", pc -> 0x000000000000405d8c +0, 0x405d8c, 0x2a1703e0, "mov w0, w23", pc -> 0x000000000000405d90 +0, 0x405d90, 0x94004c20, "bl #0x418e10", pc -> 0x000000000000418e10 +0, 0x418e10, 0x93407c02, "sxtw x2, w0", pc -> 0x000000000000418e14 +0, 0x418e14, 0x900003c4, "adrp x4, #0x490000", pc -> 0x000000000000418e18 +0, 0x418e18, 0xf946f084, "ldr x4, [x4, #0xde0]", load, 0x00490de0, pc -> 0x000000000000418e1c +0, 0x418e1c, 0xd53bd043, "mrs x3, tpidr_el0", pc -> 0x000000000000418e20 +0, 0x418e20, 0xaa0203e0, "mov x0, x2", pc -> 0x000000000000418e24 +0, 0x418e24, 0xd2800bc8, "movz x8, #0x5e", pc -> 0x000000000000418e28 +0, 0x418e28, 0xd4000001, "svc #0" +``` + +Now, here is the same part of the execution but without the `-one-insn-per-tb` option: + +```raw +0, 0x40e470, 0x54000040, "b.eq #0x40e478" +0, 0x40e474, 0xd65f03c0, "ret ", pc -> 0x00000000000040d38c +0, 0x40d38c, 0xf945fab5, "ldr x21, [x21, #0xbf0]", load, 0x00490bf0 +0, 0x40d390, 0xf9404fe0, "ldr x0, [sp, #0x98]", load, 0x7f4d42108f28 +0, 0x40d394, 0xf94002a1, "ldr x1, [x21]", load, 0x0048f9e8 +0, 0x40d398, 0xeb010000, "subs x0, x0, x1" +0, 0x40d39c, 0xd2800001, "movz x1, #0" +0, 0x40d3a0, 0x540006e1, "b.ne #0x40d47c", pc -> 0x00000000000040d3a4 +0, 0x40d3a4, 0x2a1903e0, "mov w0, w25" +0, 0x40d3a8, 0xa94153f3, "ldp x19, x20, [sp, #0x10]", load, 0x7f4d42108ea0 +0, 0x40d3ac, 0xa9425bf5, "ldp x21, x22, [sp, #0x20]", load, 0x7f4d42108eb0 +0, 0x40d3b0, 0xa94363f7, "ldp x23, x24, [sp, #0x30]", load, 0x7f4d42108ec0 +0, 0x40d3b4, 0xa9446bf9, "ldp x25, x26, [sp, #0x40]", load, 0x7f4d42108ed0 +0, 0x40d3b8, 0xa8ca7bfd, "ldp x29, x30, [sp], #0xa0", load, 0x7f4d42108e90 +0, 0x40d3bc, 0xd65f03c0, "ret ", pc -> 0x000000000000405d80 +0, 0x405d80, 0xeb13029f, "cmp x20, x19" +0, 0x405d84, 0x91000694, "add x20, x20, #1" +0, 0x405d88, 0x54ffff81, "b.ne #0x405d78", pc -> 0x000000000000405d8c +0, 0x405d8c, 0x2a1703e0, "mov w0, w23" +0, 0x405d90, 0x94004c20, "bl #0x418e10", pc -> 0x000000000000418e10 +0, 0x418e10, 0x93407c02, "sxtw x2, w0" +0, 0x418e14, 0x900003c4, "adrp x4, #0x490000" +0, 0x418e18, 0xf946f084, "ldr x4, [x4, #0xde0]", load, 0x00490de0 +0, 0x418e1c, 0xd53bd043, "mrs x3, tpidr_el0" +0, 0x418e20, 0xaa0203e0, "mov x0, x2" +0, 0x418e24, 0xd2800bc8, "movz x8, #0x5e" +0, 0x418e28, 0xd4000001, "svc #0" +``` + +The [documentation](https://www.qemu.org/docs/master/devel/tcg-plugins.html) says: + +> This plugin can also dump registers when they change value. Specify the name of the registers with multiple reg options. + +The `pc` register changes for each instruction. I would expect the plugin to produce the same output with or without the `-one-insn-per-tb` option. +Additional information: +The code that prints "pc -> 0x......" is in `insn_check_regs()` in `contrib/plugins/execlog.c`. It uses the new `qemu_plugin_read_register()` function and compares the new value to the previous value. The code seems OK. It means that the implementation of `qemu_plugin_read_register()` gets the same value several times in a row, instead of a new value each time. diff --git a/results/classifier/gemma3:12b/debug/2210 b/results/classifier/gemma3:12b/debug/2210 new file mode 100644 index 000000000..cc961971a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2210 @@ -0,0 +1,56 @@ + +contrib/plugins/execlog.c: warning: passing argument 2 of ‘g_ptr_array_add’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] +Description of problem: +Hit some warning messages when compiling upstream qemu +Steps to reproduce: +1. Clone repo and compile it + + 1.1 git clone https://gitlab.com/qemu-project/qemu.git + + 1.2 mkdir build + + 1.3 cd build/ + + 1.4 ../configure --target-list=x86_64-softmmu --enable-debug-info + + 1.5 make + +2. It will print the following warning messages: +``` +[2767/2767] Linking target tests/qtest/netdev-socket +/root/qemu/contrib/plugins/execlog.c: In function ‘registers_init’: +/root/qemu/contrib/plugins/execlog.c:339:63: warning: passing argument 2 of ‘g_ptr_array_add’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] + 339 | g_ptr_array_add(all_reg_names, reg->name); + | ~~~^~~~~~ +In file included from /usr/include/glib-2.0/glib.h:31, + from /root/qemu/contrib/plugins/execlog.c:9: +/usr/include/glib-2.0/glib/garray.h:192:62: note: expected ‘gpointer’ {aka ‘void *’} but argument is of type ‘const char *’ + 192 | gpointer data); + | ~~~~~~~~~~~~~~~~~~^~~~ +``` +Additional information: +1. After Eugenio Perez Martin (eperezma@redhat.com) debug, we found this problem introduced by this commit: +``` +commit af6e4e0a22c18a7cc97650caec56ed99c9899dd7 +Author: Alex Bennée <alex.bennee@linaro.org> +Date: Tue Feb 27 14:43:32 2024 +0000 + + contrib/plugins: extend execlog to track register changes +``` +2. The latest commit in my env: +``` +commit db596ae19040574e41d086e78469014191d7d7fc (origin/staging, origin/master, origin/HEAD) +Merge: 7d4e29ef80 7558300c53 +Author: Peter Maydell <peter.maydell@linaro.org> +Date: Tue Mar 5 13:54:54 2024 +0000 + + Merge tag 'pull-target-arm-20240305' of https://git.linaro.org/people/pmaydell/qemu-arm into staging + + target-arm queue: + * raspi: Implement Broadcom Serial Controller (BSC) for BCM2835 boards + * hw/char/pl011: Add support for loopback + * STM32L4x5: Implement RCC clock control device + * target/arm: Do memory type alignment checks + * atomic.h: Reword confusing comment for qatomic_cmpxchg + * qemu-options.hx: Don't claim "-serial" has limit of 4 serial ports +``` diff --git a/results/classifier/gemma3:12b/debug/2214 b/results/classifier/gemma3:12b/debug/2214 new file mode 100644 index 000000000..cd81dd92f --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2214 @@ -0,0 +1,2 @@ + +QEMU gdbstub does not report SIGALRM diff --git a/results/classifier/gemma3:12b/debug/2223 b/results/classifier/gemma3:12b/debug/2223 new file mode 100644 index 000000000..be1e8a3a9 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2223 @@ -0,0 +1,36 @@ + +Weird behavior on RISC-V code running on QEMU +Description of problem: +I am currently facing some weird problems on a RISC-V project meant to run on the QEMU environment and thought that maybe someone here could give me a light on the subject. The goal is to run a project built on top of one of FreeRTOS' official demo ports that target the 'virt' QEMU board. I ran across a few weird behaviors where code execution would just hang at some point (QEMU would keep execution but the expected terminal output would never come up). I don't have sufficient knowledge to tell whether the issue is with the FreeRTOS port, the RISC-V gnu toolchain or QEMU itself, hence why I am raising my hand for help on all related channels. + +This [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) contains more details and a sample project that illustrates well one of the problems I've been getting lately (I also give more context about it [here](https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1434)). It basically goes like this: the program **executes fine** when a certain code snippet is encapsulated **within a function**, but "**crashes**" (i.e. hangs) when the same snippet is placed **directly in the main code**: + +```c +for(int i=0; i < NUMBER_OF_ITEMS; i++){ + createAndPushItem(i); + + // the function above does the exact same thing as the commented code below + // yet, the commented code does not work and will crash the program. but why?? + + // int index = priorities[i]; + // void *value = (void *) getValue(i + 1); + // LinkedListItem_t *item = createItem(index, value); + // if(item){ + // push(item, &list); + // } +} +``` + +The scope shouldn't matter at all here, since there is no local variable being used or anything like that. I have tested workarounds like removing compiling optimization (i.e. changing -Os for -O0) and using regular malloc() instead of FreeRTOS' dynamic allocation API, but all without success. Note that even though the project is build on top of the FreeRTOS demo port, no RTOS functionality is used within this code to make it as simple as it gets. +Steps to reproduce: +1. clone this [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) +2. follow the readme to install the toolchain +3. follow the readme to compile the program and run it +Additional information: +The expected output is supposed to be: + + + +but when one decides to use the commented snippet instead of the function, the program hangs right before sorting the linked list for the first time: + + diff --git a/results/classifier/gemma3:12b/debug/2247 b/results/classifier/gemma3:12b/debug/2247 new file mode 100644 index 000000000..396c85100 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2247 @@ -0,0 +1,7 @@ + +virsh qemu-monitor-command --hmp help information missing inject-nmi for watchdog_action +Description of problem: +watchdog_action missing inject-nmi which already supported in Commit [795dc6e4](https://gitlab.com/qemu-project/qemu/-/commit/795dc6e46d953d70b4b7ddd3f4956f8f4b9d8565) +Steps to reproduce: +1. virsh qemu-monitor-command <id> --hmp help |grep watchdog +2. change watchdog action to inject-nmi diff --git a/results/classifier/gemma3:12b/debug/2258 b/results/classifier/gemma3:12b/debug/2258 new file mode 100644 index 000000000..4172c8173 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2258 @@ -0,0 +1,24 @@ + +Breakpoint setting not working on apple Mac host +Description of problem: +1. When use with parameter "-machine virt,accel=hvf -cpu host" to run launch a emulator, it can't set breakpoint and will report error: "warning: failed to set breakpoint site at 0xffff800081bf03cc for breakpoint 1.1: error: 34 sending the breakpoint request" +but if not use with parameter "-machine virt -cpu cortex-a57"，The breakpoint can be set successfully. + +2. Set hardware breakpoint with lldb command "breakpoint set -H -a 0xFFFF800080000000" not report error, but can't hint breakpoint. I try set breakpoint on a old x86 MacOS, It will hint breakpoint successfully. + +3. I also try run qemu-system-x86_64 emulator on apple silicon mac, It also can't hint hardware breakping. The command is: +``` +qemu-system-x86_64 -machine q35,accel=tcg -smp cpus=8 \ + -kernel arch/x86/boot/bzImage \ + -append "okaslr"\ + -nographic -serial mon:stdio \ + -m 16G \ + -s -S +``` +Steps to reproduce: +1. Launch qemu on Apple silicon Mac. Remember to user "hvf" +2. Launch lldb or gdb to set breakpoint. +3. Set breakpoint and hardware breakpoint. +4. resume to run qemu by lldb. +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/2266 b/results/classifier/gemma3:12b/debug/2266 new file mode 100644 index 000000000..e13840870 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2266 @@ -0,0 +1,70 @@ + +qemu-system-x86_64: stuck on watchpoint hit +Description of problem: + +Steps to reproduce: +1. `gcc -O0 -g watch-bug.c -o watch-bug` +2. `gdb watch-bug` +3. gdb commands: +``` +b main +r +watch l1 +next [ correct stop on the next line ] +next [ qemu is stuck as watchpoint should be hit ] +``` +Additional information: +* NOTE: it works correctly, if 'continue' command is used instead of 'next' + + +`watch-bug.c` +```c +int i0; +long l1; + + +int main(int argc, char* argv[]) +{ + i0 = argc; + l1 = i0 * 7; + + return 0; +} + +``` + +Log: +```c +Log: +root@qemux86-64:~# gdb watch-bug +GNU gdb (GDB) 13.2 +Copyright (C) 2023 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-poky-linux". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from watch-bug... +(gdb) b main +Breakpoint 1 at 0x1134: file watch-bug.c, line 8. +(gdb) r +Starting program: /home/root/watch-bug +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/libthread_db.so.1". + +Breakpoint 1, main (argc=1, argv=0x7fffffffecd8) at watch-bug.c:8 +8 i0 = argc; +(gdb) watch l1 +Hardware watchpoint 2: l1 +(gdb) next +9 l1 = i0 * 7; +(gdb) next +``` diff --git a/results/classifier/gemma3:12b/debug/2279 b/results/classifier/gemma3:12b/debug/2279 new file mode 100644 index 000000000..0773153aa --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2279 @@ -0,0 +1,26 @@ + +Debugging with Lauterbach Trace32 -> Cortex-A76, no SP register update +Description of problem: +We do not see changes in the SP_EL1 register value when debugging the QEMU application with Lauterbach Trace32. +Steps to reproduce: +1. Compile bare metal code that uses push and pop instructions (stack). +2. Run QEMU with bare metal code. +3. Connect via Lauterbach Trace32 and check the displayed SP register value. +Additional information: + +This is a screenshot from QEMU 8.0.0, but updating to QEMU 8.2.0 does not resolve the problem. + +I have discussed this with Lauterbach Trace32 support with these results: +- Trace32 uses RSP protocol `p` packets to read some registers, including SP_EL1. GDB seems to use `g` packet. +- QEMU responds to `p` packet with an invalid value, which causes Trace32 to display invalid value. + +Some related RSP protocol logs from Trace32. + + + +Different part of RSP protocol log: +``` +Sending packet: $p20#d2 ... +receiving packet: ec00004000000000 +``` +So it looks like Trace32 can receive different values that zero as response to `p` packet. diff --git a/results/classifier/gemma3:12b/debug/2288 b/results/classifier/gemma3:12b/debug/2288 new file mode 100644 index 000000000..85eee2c37 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2288 @@ -0,0 +1,30 @@ + +ERROR: Unrecognized host OS (uname -s reports 'Linux') +Description of problem: +Hit "Unrecognized host OS (uname -s reports 'Linux')" ERROR when run configure file on upstream qemu. +Steps to reproduce: +1.Clone repo and compile it + + 1.1 git clone https://gitlab.com/qemu-project/qemu.git + + 1.2 cd qemu + + 1.3 mkdir build + + 1.4 cd build + + 1.5 ../configure --target-list=x86_64-softmmu --enable-debug + +2.The following ERROR message: + +ERROR: Unrecognized host OS (uname -s reports 'Linux') +Additional information: +Cpu information: + +Vendor ID: AuthenticAMD + + BIOS Vendor ID: Advanced Micro Devices, Inc. + + Model name: AMD EPYC 9754 128-Core Processor + + BIOS Model name: AMD EPYC 9754 128-Core Processor diff --git a/results/classifier/gemma3:12b/debug/2307 b/results/classifier/gemma3:12b/debug/2307 new file mode 100644 index 000000000..95d5e6503 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2307 @@ -0,0 +1,40 @@ + +QEMU Windows COM port filenames not recognized i.e. \\.\COM19 or \\.\CNCA0 +Steps to reproduce: +1. Run qemu-system-arm with the comand line above. +2. QEMU fails with `qemu-system-arm.exe: -gdb \\.\CNCA8: '\\.\CNCA8' is not a valid char driver` +3. ```qemu-system-arm.exe -machine mps2-an500 -gdb \\.\COM19 +qemu-system-arm.exe: -gdb \\.\COM19: '\\.\COM19' is not a valid char driver +``` +Additional information: +Windows allows COM ports numbered 10 and higher to be prefixed with a `\\.\` escape as in `\\.\COM17`. Such COM port assignments are not uncommon when a plurality of USB serial adapters. +Equally problematic are virtual COM port designations such as `\\.\CNCA8` created by the Windows 10x64 driver package known as `com0com`: https://pete.akeo.ie/2011/07/com0com-signed-drivers.html + +Upon checking the source pulled from the Github mirror an initial fix was to simply modify /chardev/char.c, but this appears insufficient. Sadly. + +Please ask if more information is required. I am actively working on extending an existing QEMU machine emulation. A patch to fix this problem is below. Please comment if applicable. + +Jerry. + +``` +diff --git a/chardev/char.c b/chardev/char.c +index 3c43fb1278..7a3f342c72 100644 +--- a/chardev/char.c ++++ b/chardev/char.c +@@ -418,6 +418,13 @@ QemuOpts *qemu_chr_parse_compat(const char *label, const char *filename, + qemu_opt_set(opts, "path", filename, &error_abort); + return opts; + } ++ // JME ++ if (strstart(filename, "\\\\.\\", NULL)) { ++ qemu_opt_set(opts, "backend", "serial", &error_abort); ++ qemu_opt_set(opts, "path", filename, &error_abort); ++ return opts; ++ } ++ + if (strstart(filename, "file:", &p)) { + qemu_opt_set(opts, "backend", "file", &error_abort); + qemu_opt_set(opts, "path", p, &error_abort); + +``` +/label ~"kind::Bug" diff --git a/results/classifier/gemma3:12b/debug/2309 b/results/classifier/gemma3:12b/debug/2309 new file mode 100644 index 000000000..3c057ba8f --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2309 @@ -0,0 +1,32 @@ + +qemu-aarch64 hangs running cargo test after libc6 upgrade to 2.36-9+deb12u6 +Description of problem: +qemu-aarch64 seems to hang with 100% cpu usage without any indication. +with -p 12345 for gdb debugging, gdb could not interrupt the remote with ctrl-c. +Steps to reproduce: +1. Ensure the test env has 2.36-9+deb12u6 +2. Install the latest rust toolchain. +3. mkdir test_test && cargo init +4. ensure src/main.rs has +``` +fn main() { + println!("Hello, world!"); +} + +#[test] +fn test() { + println!("hAAA!"); +} +``` +5. create .cargo/config.toml +``` +[target.aarch64-unknown-linux-gnu] +linker = "aarch64-linux-gnu-gcc" +runner = "qemu-aarch64 -L /usr/aarch64-linux-gnu" +rustflags = ["-C", "target-cpu=neoverse-n1"] +``` +6. cargo test --target aarch64-unknown-linux-gnu +Additional information: +The issue does not seem to occur with libc6:2.36-9+deb12u4 + +The same binary runs fine on a real arm64 target with the upgraded libc6 version 2.36-9+deb12u6. diff --git a/results/classifier/gemma3:12b/debug/2329 b/results/classifier/gemma3:12b/debug/2329 new file mode 100644 index 000000000..87183e600 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2329 @@ -0,0 +1,2 @@ + +Windows 64-bit, qemu-monitor, change diff --git a/results/classifier/gemma3:12b/debug/2332 b/results/classifier/gemma3:12b/debug/2332 new file mode 100644 index 000000000..c6f795905 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2332 @@ -0,0 +1,30 @@ + +Riscv semihosting arguments parsing issue +Description of problem: +When executing a bare metal kernel in semihosting mode with "argv" arguments provided through "-append" or "-semihostgin-config", recovering the arguments will read out-of-bound memory in the guest and often make the emulation crash through a hard fault. +Steps to reproduce: +1. Compile the simplest "kernel" in semihosting mode, e.g. test.c containing: + + `#include <stdio.h>` + + `#include <stdlib.h>` + + `int main(int argc, char *argv[])` + + `{ unsigned int i; printf("[+] Test OK!\n"); for(i = 0; i < argc; i++){ printf("Arg %d is '%s'\n", i, argv[i]); } return 0; }` +2. One can compile the previous example under Debian with + + `riscv64-unknown-elf-gcc -static -fPIC -march=rv64imac -mabi=lp64 -specs=picolibc.specs --crt0=semihost --oslib=semihost -Triscv_layout.ld test.c -o test` + + This supposes the bare metal cross-toolchain `binutils-riscv64-unknown-elf` to be installed, as well as the standard library picolibc `picolibc-riscv64-unknown-elf` that supports semihosting. + + The `riscv_layout`.ld file contains: + + `__flash = 0x80000000; __flash_size = 0x00080000; __ram = 0x80080000; __ram_size = 0x40000; __stack_size = 1k; INCLUDE picolibc.ld` +3. Execute the command line: + - `qemu-system-riscv64 -semihosting-config enable=on -monitor none -serial none -nographic -machine sifive_u,accel=tcg -no-reboot -bios none -kernel /tmp/test -append "10 20"` +4. Observe the following as an example of the bug: + + `[+] Test OK! Arg rg A is '/tmp/test0' Arg Arg 2 is 'RISCV fault x0 -2146959259z' ero 0x0000000000000000 x1 ra 0x0000000080000e94 x2 sp 0x00000000800bfea0 x3 gp 0x0000000080080820 x4 tp 0x0000000080080028 x5 t0 0x00000000800019a2 x6 t1 0x000000000000002a x7` +Additional information: +The same bug seems to affect risv32 and riscv64 system emulators. The semihosting part seems to work well when there is no access to the "argv" arguments. diff --git a/results/classifier/gemma3:12b/debug/2333 b/results/classifier/gemma3:12b/debug/2333 new file mode 100644 index 000000000..765c54a3b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2333 @@ -0,0 +1,46 @@ + +VDSO on armeb seems broken +Description of problem: +I'm seeing the VDSO method for `__clock_gettime64()` crashing under `qemu-armeb` (stack trace under Additional information, below). + +I rebuilt glibc with VDSO globally kludged off, and all was well. +Steps to reproduce: +``` +#include <time.h> +#include <stdlib.h> +#include <stdio.h> + +int main(int argc, char **argv) { + time_t ts; + printf("%ld\n", time(&ts)); + exit(0); +} +``` + +Results, first with VDSO active via a system snapshot, second with the patched glibc: +``` +$ armeb-linux-gnueabihf-gcc -o /tmp/time /tmp/time.c +$ qemu-armeb -L /.mirrorsnaps/.rootsnap.prev/usr/armeb-linux-gnueabihf /tmp/time +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +$ qemu-armeb -L /usr/armeb-linux-gnueabihf /tmp/time +1715123280 +``` +Additional information: +``` +Program received signal SIGSEGV, Segmentation fault. +0x4082b462 in ?? () +(gdb) bt +#0 0x4082b462 in ?? () +#1 0x40bf64a4 in __GI___clock_gettime64 (clock_id=clock_id@entry=5, tp=tp@entry=0x407fe9c0) + at ../sysdeps/unix/sysv/linux/clock_gettime.c:42 +#2 0x40be9f58 in __GI___time64 (timer=0x0) at ../sysdeps/unix/sysv/linux/time.c:60 +#3 __time (timer=0x407fea04) at ../sysdeps/unix/sysv/linux/time.c:73 +``` + +`clock_gettime.c:42` is +``` + r = INTERNAL_VSYSCALL_CALL (vdso_time64, 2, clock_id, tp); +``` + +Interestingly, the problem doesn't occur on qemu-arm (little endian), all else equal. diff --git a/results/classifier/gemma3:12b/debug/2380 b/results/classifier/gemma3:12b/debug/2380 new file mode 100644 index 000000000..54c04e20a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2380 @@ -0,0 +1,106 @@ + +Crash on x86_64 vm launch +Description of problem: +When I started using QEMU for x86 OS programming about a year or 2 ago it ran fine until about a year ago where it just does not launch for more than a few seconds, it always crashes with no output at all, even when running with debug options enabled, it still outputs normal values before just crashing or exiting, this happens when running with an OS image or not, I have tried everything possible (wiping the whole system of anything including "qemu" including the registry, disabling all AV including windows defender, using SFC and DISM to repair corrupt files, installing the oldest versions of qemu up to the newest, running the program in different compatibility modes, running as admin, changing install directories, disabling overclocking, and many more) the only way it runs is if I use a VM to run qemu or reinstall windows, I am not reinstalling windows and im not running a vm to run another vm, my OS is very stable apart from this one program, I need to use QEMU as it is very important for my OS builds as it allows me to automate many things. +Steps to reproduce: +1. launch qemu-system-x86_64 + +unable to reproduce on other clean OS installs +Additional information: +upon clean building QEMU from latest build using MSYS2 and running GDB here is the output + +``` +(gdb) run +Starting program: C:\qemu\build\qemu-system-x86_64.exe +[New Thread 22292.0x250c] +[New Thread 22292.0x2004] +[New Thread 22292.0x1d2c] +[New Thread 22292.0x5614] +[New Thread 22292.0x5b3c] +[New Thread 22292.0x5ae8] +[New Thread 22292.0x2d04] +[New Thread 22292.0x5588] +[New Thread 22292.0x3ce8] +gdb: unknown target exception 0xc0000409 at 0x7ffac8f83e74 + +Thread 8 received signal ?, Unknown signal. +[Switching to Thread 22292.0x2d04] +0x00007ffac8f83e74 in strerror_s () from C:\Windows\System32\msvcrt.dll + +``` + +the error code leads to STATUS_STACK_BUFFER_OVERRUN + +upon back tracing this it leads to this output + +``` +(gdb) bt +#0 0x00007ffac8f83e74 in strerror_s () from C:\Windows\System32\msvcrt.dll +#1 0x00007ffac8f82c04 in msvcrt!longjmp () from C:\Windows\System32\msvcrt.dll +#2 0x00007ff670af2b8e in advance_pc (env=0x34d3c60, s=0x4beff8d0, num_bytes=4) + at ../target/i386/tcg/translate.c:2131 +#3 0x00007ff670af2d33 in x86_ldl_code (env=0x34d3c60, s=0x4beff8d0) + at ../target/i386/tcg/translate.c:2169 +#4 0x00007ff670af3939 in insn_get (env=0x34d3c60, s=0x4beff8d0, ot=MO_32) + at ../target/i386/tcg/translate.c:2454 +#5 0x00007ff670b0c4ca in disas_insn (s=0x4beff8d0, cpu=0x34d1450) + at ../target/i386/tcg/translate.c:5148 +#6 0x00007ff670b1253f in i386_tr_translate_insn (dcbase=0x4beff8d0, cpu=0x34d1450) + at ../target/i386/tcg/translate.c:7023 +#7 0x00007ff670ba30b2 in translator_loop (cpu=0x34d1450, tb=0x3b3a280, max_insns=0x4beffba4, + pc=954352, host_pc=0x43de8ff0, ops=0x7ff671a9b480 <i386_tr_ops>, db=0x4beff8d0) + at ../accel/tcg/translator.c:164 +#8 0x00007ff670b127ef in gen_intermediate_code (cpu=0x34d1450, tb=0x3b3a280, + max_insns=0x4beffba4, pc=954352, host_pc=0x43de8ff0) at ../target/i386/tcg/translate.c:7099 +#9 0x00007ff670ba1abd in setjmp_gen_code (env=0x34d3c60, tb=0x3b3a280, pc=954352, + host_pc=0x43de8ff0, max_insns=0x4beffba4, ti=0x4beffbc0) at ../accel/tcg/translate-all.c:278 +#10 0x00007ff670ba1de3 in tb_gen_code (cpu=0x34d1450, pc=954352, cs_base=0, flags=176, + cflags=-16646144) at ../accel/tcg/translate-all.c:358 +#11 0x00007ff670b96508 in cpu_exec_loop (cpu=0x34d1450, sc=0x4beffd60) + at ../accel/tcg/cpu-exec.c:989 +#12 0x00007ff670b96689 in cpu_exec_setjmp (cpu=0x34d1450, sc=0x4beffd60) + at ../accel/tcg/cpu-exec.c:1035 +#13 0x00007ff670b96728 in cpu_exec (cpu=0x34d1450) at ../accel/tcg/cpu-exec.c:1061 +--Type <RET> for more, q to quit, c to continue without paging-- +#14 0x00007ff670bc1fb7 in tcg_cpu_exec (cpu=0x34d1450) at ../accel/tcg/tcg-accel-ops.c:76 +#15 0x00007ff670bc28a2 in mttcg_cpu_thread_fn (arg=0x34d1450) + at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#16 0x00007ff670de8587 in win32_start_routine (arg=0x3537c60) at ../util/qemu-thread-win32.c:411 +#17 0x00007ffac8f8e634 in msvcrt!_beginthreadex () from C:\Windows\System32\msvcrt.dll +#18 0x00007ffac8f8e70c in msvcrt!_endthreadex () from C:\Windows\System32\msvcrt.dll +#19 0x00007ffac901257d in KERNEL32!BaseThreadInitThunk () from C:\Windows\System32\kernel32.dll +#20 0x00007ffacae0aa48 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll +#21 0x0000000000000000 in ?? () + +``` + +if I am reading the output correctly qemu/target/i386/tcg/translate.c:2131 is the last file (in source) it accesses before moving to msvcrt.dll, inside of the advance_pc function + + +this is the function + +``` +static uint64_t advance_pc(CPUX86State *env, DisasContext *s, int num_bytes) { + uint64_t pc = s->pc; + + if (s->base.num_insns > 1 && !is_same_page(&s->base, s->pc + num_bytes - 1)) { + siglongjmp(s->jmpbuf, 2); <-------------------------------------------------- The line is the last function call + } + + s->pc += num_bytes; + + if (unlikely(cur_insn_len(s) > X86_MAX_INSN_LENGTH)) { + if (((s->pc - 1) ^ (pc - 1)) & TARGET_PAGE_MASK) { + volatile uint8_t unused = cpu_ldub_code(env, (s->pc - 1) & TARGET_PAGE_MASK); + (void)unused; + } + siglongjmp(s->jmpbuf, 1); + } + + return pc; +} +``` + +if I had to guess this problem could be caused by some windows configuration, something to do with memory, or maybe some corrupt files, but I am unsure + +I am not a c programmer so I don't know much about the code but I can debug more if needed diff --git a/results/classifier/gemma3:12b/debug/2385 b/results/classifier/gemma3:12b/debug/2385 new file mode 100644 index 000000000..b6b185ed2 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2385 @@ -0,0 +1,108 @@ + +sparc: SIGILL stepping over `std` in gdb +Description of problem: +Certain cases of single-stepping thru the `std` store double-word instruction causes SIGILL fatal trap, while normal execution of the program is fine. Unfortunately I do not have access to real SPARC hardware so I cannot attest whether this is an emulation issue or not. + +My previous bugfix #2281 fixed any single-stepping in a debugger from panicking the kernel, associated with the `lda` on ASI_USERTXT in the `default_fuword32` function. I suspect further bugs like this could be related somehow. Perhaps a different instruction is used for the 64-bit access that needs a similar fix. + +This problem was experienced while testing some shell-spawning assembly: +``` +-bash-4.3$ cat test.s +.section ".text" +.global main +main: + sethi %hi(0x2f626800), %l6 + or %l6, 0x16e, %l6 ! 0x2f62696e + sethi %hi(0x2f6b7000), %l7 + or %l7, 0x368, %l7 ! 0x2f6b7368 + and %sp, %sp, %o0 + add %sp, 0xc, %o1 + xor %o2, %o2, %o2 + add %sp, 0x14, %sp + std %l6, [ %sp + -20 ] + clr [ %sp + -12 ] + st %sp, [ %sp + -8 ] + clr [ %sp + -4 ] + mov 0x3b, %g1 + ta 8 + xor %o7, %o7, %o0 + mov 1, %g1 + ta 8 +``` + +``` +-bash-4.3$ gcc test.s -o test +-bash-4.3$ ./test +$ echo HELLO +HELLO +$ exit +``` + +As you can see the program works when ran directly from the shell, but when single-stepping in gdb, a SIGILL (illegal instruction) trap occurs +``` +-bash-4.3$ gdb test +GNU gdb (GDB) 7.4.1 +[...] +(gdb) disas main +Dump of assembler code for function main: + 0x0001061c <+0>: sethi %hi(0x2f626800), %l6 + 0x00010620 <+4>: or %l6, 0x16e, %l6 ! 0x2f62696e + 0x00010624 <+8>: sethi %hi(0x2f6b7000), %l7 + 0x00010628 <+12>: or %l7, 0x368, %l7 ! 0x2f6b7368 + 0x0001062c <+16>: and %sp, %sp, %o0 + 0x00010630 <+20>: add %sp, 0xc, %o1 + 0x00010634 <+24>: xor %o2, %o2, %o2 + 0x00010638 <+28>: add %sp, 0x14, %sp + 0x0001063c <+32>: std %l6, [ %sp + -20 ] + 0x00010640 <+36>: clr [ %sp + -12 ] + 0x00010644 <+40>: st %sp, [ %sp + -8 ] + 0x00010648 <+44>: clr [ %sp + -4 ] + 0x0001064c <+48>: mov 0x3b, %g1 + 0x00010650 <+52>: ta 8 + 0x00010654 <+56>: xor %o7, %o7, %o0 + 0x00010658 <+60>: mov 1, %g1 + 0x0001065c <+64>: ta 8 +End of assembler dump. +(gdb) b main +Breakpoint 1 at 0x1061c +(gdb) r +Starting program: /export/home/bazz/iob/test + +Breakpoint 1, 0x0001061c in main () +(gdb) si +0x00010620 in main () +(gdb) +0x00010624 in main () +[...] +Program received signal SIGILL, Illegal instruction. +0x0001063c in main () +``` + +However, if I continue execution _over_ the `std` instruction, the SIGILL does not occur. it will get to the usual SIGTRAP after execve, +but then complains about memory accesses that I've never seen before. +``` +(gdb) r +Starting program: /export/home/bazz/iob/test + +Breakpoint 1, 0x0001061c in main () +(gdb) c +Continuing. + +Program received signal SIGTRAP, Trace/breakpoint trap. +0xef783af4 in _rt_boot () from /usr/lib/ld.so.1 +(gdb) c +Continuing. +Cannot access memory at address 0x2800007 +Cannot access memory at address 0x2800003 +(gdb) c +Continuing. +Cannot access memory at address 0x2800007 +Cannot access memory at address 0x2800003 +(gdb) c +Continuing. +$ +``` + +It does eventually get a shell though. + +On mdb, instead of single-stepping into a SIGILL, everything goes unresponsive after stepping the `std` instruction. Then I have to kill mdb. diff --git a/results/classifier/gemma3:12b/debug/245 b/results/classifier/gemma3:12b/debug/245 new file mode 100644 index 000000000..36c7c7e96 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/245 @@ -0,0 +1,2 @@ + +watchpoints might not properly stop execution at the right address diff --git a/results/classifier/gemma3:12b/debug/2465 b/results/classifier/gemma3:12b/debug/2465 new file mode 100644 index 000000000..5c8e7b5b2 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2465 @@ -0,0 +1,2 @@ + +QEMU does not stop other threads when hitting a breakpoint diff --git a/results/classifier/gemma3:12b/debug/2477 b/results/classifier/gemma3:12b/debug/2477 new file mode 100644 index 000000000..21beaa42a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2477 @@ -0,0 +1,2 @@ + +GDB_HAS_MTE detection is incomplete diff --git a/results/classifier/gemma3:12b/debug/2479 b/results/classifier/gemma3:12b/debug/2479 new file mode 100644 index 000000000..3c5dc1964 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2479 @@ -0,0 +1,31 @@ + +Unable to remotely debug with gdbserver on debian while using qemu-system-m68k emulator +Description of problem: +When I use gdb-multiarch to try to connect to the gdbserver running on the guest machine the error message below is displayed by the gdbserver: + +``` +/build/gdb-Lhte76/gdb-13.2/gdbserver/tdesc.cc:195: A problem internal to GDBserver has been detected. +tdesc_get_features_xml: Assertion `tdesc->xmltarget != NULL || (!tdesc->features.empty () && tdesc->arch != NULL)' failed. +``` + +and the program execution is terminated abruptly. +Steps to reproduce: +1. Download the Debian Motorola 680x0 Port and install it using QEmu. +2. Update to unstable version (optional). +3. Download and install gdbserver and also a compiler for the C language. +4. Write a hello world and compile. +5. Run gdbserver targeting the program from the previous step. +6. Try connecting using gdb-multiarch. +Additional information: +The error persists when I download the QEmu source code and compile it. + +If this procedure is done with an older version of gdbserver (such as 7.12) then I can connect normally. However, if a breakpoint is placed anywhere in the program and if it is reached at any point during execution and if after it is reached the 'continue' command is entered, then the error message below is displayed by the gdbserver: + +``` +linux-low.c:2627: A problem internal to GDBserver has been detected. +int maybe_hw_step(thread_info*): Assertion `has_reinsert_breakpoints (thread)' failed. +``` + +and the program execution is terminated abruptly. + +I think it's working on real hardware. diff --git a/results/classifier/gemma3:12b/debug/2483 b/results/classifier/gemma3:12b/debug/2483 new file mode 100644 index 000000000..8b0db0191 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2483 @@ -0,0 +1,21 @@ + +m68k: jsr (sp) doesn't work as expected +Description of problem: +Consider the following code (disassembly from ghidra). This copies the current `SP` to `A1` then copies 0x68 bytes from the address pointed at by `A0` to the address pointed at by `A1` with increment. This should end up with a copy of some bytes and `SP` pointing at the first. + +``` + ff8241e6 22 4f movea.l SP,A1 + ff8241e8 70 68 moveq #0x68,D0 + LAB_ff8241ea XREF[1]: ff8241ee(j) + ff8241ea 12 d8 move.b (A0)+,(A1)+ + ff8241ec 53 80 subq.l #0x1,D0 + ff8241ee 66 fa bne.b LAB_ff8241ea + ff8241f0 4e 97 jsr (SP) +``` + +`SP` is `0x3bfc` at the `jsr` so we'd expect to jump to `0x3bfc` and put the address to return to at `0x3bf8` so the `jsr` can return I think? +What currently happens in QEMU is the return address is put at `0xb3f8` and `PC` also becomes `0x3bf8` and the return address starts being executed as code and things go off the rails. + +Forgive the screenshot but this is what it looks like with GDB connected. Dumping the memory where the `PC` is shows that the return address is actually there and we can see there is garbage before the instructions it should be executing. + +{width=289 height=759} diff --git a/results/classifier/gemma3:12b/debug/2489 b/results/classifier/gemma3:12b/debug/2489 new file mode 100644 index 000000000..c2b245dd0 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2489 @@ -0,0 +1,93 @@ + +qemu-system-x86_64 TCG coredumps when using qemu_plugin_register_vcpu_mem_cb +Description of problem: +QEMU freezes, then exits with `Segmentation fault (core dumped)`. +Steps to reproduce: +1. Install Windows 7 SP1 into `disk.qcow2`. +2. Start the machine, and use `savevm snapshot` at the login screen, then exit. +3. `./qemu-system-x86_64 -m 1G -M q35 -drive file=disk.qcow2 -nic none -loadvm snapshot -plugin contrib/plugins/libexeclog.so` +Additional information: +QEMU runs normally without the plugin. + +This bug can also be reproduced with a simpler plugin just calling `qemu_plugin_register_vcpu_mem_cb` once per instruction: +[minimal_plugin.diff](/uploads/6e6c1af21df90379e726e693a53f7b8f/minimal_plugin.diff). + +Log using `-d op,in_asm,out_asm,plugin -D log`: [log.gz](/uploads/ccfd26c4845422d63f72a357f8fc1137/log.gz) + +GDB full backtrace: +``` +(gdb) bt f +#0 stw_he_p (v=0, ptr=0x2) at /REDACTED/qemu/include/qemu/bswap.h:265 +No locals. +#1 stw_le_p (v=0, ptr=0x2) at /REDACTED/qemu/include/qemu/bswap.h:319 +No locals. +#2 access_stw (ac=ac@entry=0x7f1652dfec70, addr=addr@entry=18446735827410705922, val=val@entry=0) at ../target/i386/tcg/access.c:143 + p = 0x2 +#3 0x000055dfca88534e in do_xsave_fpu (ac=ac@entry=0x7f1652dfec70, ptr=ptr@entry=18446735827410705920) at ../target/i386/tcg/fpu_helper.c:2537 + env = 0x55dff34fe630 + fpus = 0 + fptag = <optimized out> + i = <optimized out> + addr = <optimized out> +#4 0x000055dfca88caf8 in do_fxsave (ptr=18446735827410705920, ac=0x7f1652dfec70) at ../target/i386/tcg/fpu_helper.c:2632 + env = 0x55dff34fe630 + env = <optimized out> +#5 helper_fxsave (env=<optimized out>, ptr=18446735827410705920) at ../target/i386/tcg/fpu_helper.c:2656 + ra = <optimized out> + ac = {vaddr = 18446735827410705920, haddr1 = 0x0, haddr2 = 0x0, size = 512, size1 = 512, mmu_idx = 4, env = 0x55dff34fe630, + ra = 139732667533971} +#6 0x00007f160c030a93 in code_gen_buffer () +No locals. +#7 0x000055dfca979986 in cpu_tb_exec (cpu=cpu@entry=0x55dff34fbe70, itb=itb@entry=0x7f160c030940 <code_gen_buffer+198931>, + tb_exit=tb_exit@entry=0x7f1652dff228) at ../accel/tcg/cpu-exec.c:458 + ret = <optimized out> + last_tb = <optimized out> + tb_ptr = 0x7f160c030a00 <code_gen_buffer+199123> + __PRETTY_FUNCTION__ = "cpu_tb_exec" +#8 0x000055dfca979edd in cpu_loop_exec_tb (tb_exit=0x7f1652dff228, last_tb=<synthetic pointer>, pc=<optimized out>, + tb=0x7f160c030940 <code_gen_buffer+198931>, cpu=0x55dff34fbe70) at ../accel/tcg/cpu-exec.c:908 + insns_left = <optimized out> + __PRETTY_FUNCTION__ = "cpu_loop_exec_tb" + insns_left = <optimized out> + _a15 = <optimized out> + _b16 = <optimized out> +#9 cpu_exec_loop (cpu=cpu@entry=0x55dff34fbe70, sc=sc@entry=0x7f1652dff2c0) at ../accel/tcg/cpu-exec.c:1022 + tb = 0x7f160c030940 <code_gen_buffer+198931> + flags = <optimized out> + cflags = 4278321152 + pc = <optimized out> + cs_base = <optimized out> + last_tb = <optimized out> + tb_exit = 1 + ret = <optimized out> +#10 0x000055dfca97a6fd in cpu_exec_setjmp (cpu=cpu@entry=0x55dff34fbe70, sc=sc@entry=0x7f1652dff2c0) at ../accel/tcg/cpu-exec.c:1039 +No locals. +#11 0x000055dfca97ae79 in cpu_exec (cpu=cpu@entry=0x55dff34fbe70) at ../accel/tcg/cpu-exec.c:1065 + ret = <optimized out> + sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = 0} + _rcu_read_auto = 0x1 +#12 0x000055dfca9a35af in tcg_cpu_exec (cpu=cpu@entry=0x55dff34fbe70) at ../accel/tcg/tcg-accel-ops.c:78 +--Type <RET> for more, q to quit, c to continue without paging--c + ret = <optimized out> + __PRETTY_FUNCTION__ = "tcg_cpu_exec" +#13 0x000055dfca9a3703 in mttcg_cpu_thread_fn (arg=arg@entry=0x55dff34fbe70) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 + r = <optimized out> + force_rcu = {notifier = {notify = 0x55dfca9a37f0 <mttcg_force_rcu>, node = {le_next = 0x0, le_prev = 0x7f1652e00528}}, cpu = 0x55dff34fbe70} + cpu = 0x55dff34fbe70 + __PRETTY_FUNCTION__ = "mttcg_cpu_thread_fn" + __func__ = "mttcg_cpu_thread_fn" +#14 0x000055dfcab7e898 in qemu_thread_start (args=0x55dff355dd80) at ../util/qemu-thread-posix.c:541 + __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {94420348558720, 3438567870158976394, -1656, 0, 140727865026624, 139734089805824, + 8803266606146106762, 3438582454403577226}, __mask_was_saved = 0}}, __pad = {0x7f1652dff430, 0x0, 0x0, 0x0}} + __cancel_routine = 0x55dfcab7e8f0 <qemu_thread_atexit_notify> + __cancel_arg = <optimized out> + __not_first_call = <optimized out> + qemu_thread_args = <optimized out> + start_routine = 0x55dfca9a3600 <mttcg_cpu_thread_fn> + arg = 0x55dff34fbe70 + r = <optimized out> +#15 0x00007f165e090272 in start_thread () from /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6 +No symbol table info available. +#16 0x00007f165e10bdec in clone3 () from /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6 +No symbol table info available. +``` diff --git a/results/classifier/gemma3:12b/debug/2524 b/results/classifier/gemma3:12b/debug/2524 new file mode 100644 index 000000000..d4b7f057f --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2524 @@ -0,0 +1,4 @@ + +Reverse debugging is broken on release and stable branches +Description of problem: +Master branch has commit 94962ff00d09674047aed896e87ba09736cd6941, which reverts incorrect commit and fix reverse debugging. But this commit is missing in 9.0.x 9.1.x releases branches and in stable branches too. diff --git a/results/classifier/gemma3:12b/debug/2544 b/results/classifier/gemma3:12b/debug/2544 new file mode 100644 index 000000000..6f7e262ee --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2544 @@ -0,0 +1,2 @@ + +Bug: qemu not properly flushing error messages related to bad arguments diff --git a/results/classifier/gemma3:12b/debug/2546 b/results/classifier/gemma3:12b/debug/2546 new file mode 100644 index 000000000..768429cce --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2546 @@ -0,0 +1,2 @@ + +Troubleshooting Data Abort Error While Debugging U-Boot on mcimx6ul-evk in QEMU diff --git a/results/classifier/gemma3:12b/debug/2554 b/results/classifier/gemma3:12b/debug/2554 new file mode 100644 index 000000000..ed75e802d --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2554 @@ -0,0 +1,12 @@ + +qemu-system-arm: thumb2: vector table branch instruction not followed +Description of problem: +When an undefined instruction is hit and causes an exception that causes a jump to the undef vector at 0x04; translation of the branch instruction found there appears to fail since instead of branching to the handler it steps to the next instruction - the next entry in the vector table, translates that, and on stepping once again moves to the next entry in the vector table. Eventually it steps out of the table and (re)enters the _start subroutine pointed to by vector 0x0. +Steps to reproduce: +This is related to issue #2542 in as much as I am hunting down failures in the picolibc 1.8.6 test suite on Debian. After fixing issues such as the failure to enable the MMU and some others via incorporating upstream commits I'm left with 10 tests, all for exception handling, that result in meson (build system) TIMEOUT instead of EXPECTEDFAIL. All of these tests should fail instantly and cause Qemu to exit but it continues - apparently spinning in an endless loop as described above until meson kills it. + +Creating a small reproducer has proved challenging and nigh impossible (for me) - even identifying the crux as described here has taken 4 days. However with the help of `qemu-system-arm -d in_asm,op,out_asm ...` and `gdb-multiarch` I believe I may have produced a focused report that will help figure this out. + +# +Additional information: +Since this is hard to debug I can give remote ssh access via `tmate` to directly control the debug session if necessary. diff --git a/results/classifier/gemma3:12b/debug/2566 b/results/classifier/gemma3:12b/debug/2566 new file mode 100644 index 000000000..57bdcfaa6 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2566 @@ -0,0 +1,120 @@ + +Plugin deadlock with qemu_plugin_register_vcpu_mem_cb introduced prior to v8.1.0 +Description of problem: +Between v8.0.5 and v8.1.0 a bug was introduced where a TCG plugin calling `qemu_plugin_register_vcpu_mem_cb` can cause a deadlock. This bug is still present in the current head of master (a66f28df650166ae8b50c992eea45e7b247f4143). + +I was able to reproduce this reliably (>95% of the time) testing with the minimal plugin shown below. In more limited testing, I found the logic in the (in-tree) hotpages plugin will also trigger this deadlock. + +I tested with the Ubuntu Bionic qcow from [here](https://panda.re/qcows/linux/ubuntu/1804/x86_64/bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2), but don't think there's anything particularly special about this qcow. + + +A minimal plugin to trigger the deadlock is as follows. To build the plugin, you'll need to add a `NAMES += customtest` line into `contrib/plugins/Makefile. + +contrib/plugins/customtest.c: +``` +#include <qemu-plugin.h> + +QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION; + +static void vcpu_mem(unsigned int cpu_index, qemu_plugin_meminfo_t info, + uint64_t vaddr, void *udata) +{} + + +static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb) +{ + struct qemu_plugin_insn *insn; + size_t n = qemu_plugin_tb_n_insns(tb); + + for (size_t i = 0; i < n; i++) { + insn = qemu_plugin_tb_get_insn(tb, i); + + /* Register callback on memory read or write */ + qemu_plugin_register_vcpu_mem_cb(insn, vcpu_mem, + QEMU_PLUGIN_CB_NO_REGS, + QEMU_PLUGIN_MEM_R, NULL); + } +} + +QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id, + const qemu_info_t *info, int argc, + char **argv) +{ + qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans); + + return 0; +} +``` +Steps to reproduce: +1. From the current head of `master` (a66f28df650166ae8b50c992eea45e7b247f4143) +2. Add the above plugin to the contrib/plugins directory and update the `contrib/plugins/Makefile` with `NAMES += customtest` so it will be built. +3. `../configure --enable-plugins --target-list=x86_64-softmmu` +4. `make && make plugins` +5. `wget https://panda.re/qcows/linux/ubuntu/1804/x86_64/bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2` +6. Launch the guest with `./qemu-system-x86_64 -m 1G -plugin contrib/plugins/libcustomtest.so bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2 -nographic -d plugin`, and wait a moment. There will be no output after the initial "Booting from Hard Disk" mesasge. Switch to the monitor with `ctrl+a c` type `quit` and press enter, qemu fails to exit because of the deadlock. +Additional information: +* I tested and saw the bug on the following commits/tags: current head of master (a66f28df650166ae8b50c992eea45e7b247f4143), v9.1.0, v9.0.0, and v8.2.6, v8.1.0. +* I tested and saw no bug on the following tags: v8.0.5, v8.0.4, v8.0.0 +* If `qemu_plugin_register_vcpu_mem_cb` is called with a fourth argument of `0` instead of `QEMU_PLUGIN_MEM_R`, the guest did not hang (at least on the current head of master). +* The monitor can still be reached with `ctrl+a c` after the deadlock, but running the `quit` command does not terminate the emulator (I don't think this is related to #1195 since things start hanging before the shutdown begins) + +Gdb shows the following backtraces (from the head of master) across the running threads. It seems that thread 3 and thread 2 are stuck, though I'm not too familiar with what they're doing. +``` +(gdb) thread apply all bt + +Thread 3 (Thread 0x7f9677fff640 (LWP 754761) "qemu-system-x86"): +#0 __futex_abstimed_wait_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x55a9c1047748 <exclusive_cond+40>) at ./nptl/futex-internal.c:57 +#1 __futex_abstimed_wait_common (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x55a9c1047748 <exclusive_cond+40>) at ./nptl/futex-internal.c:87 +#2 __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x55a9c1047748 <exclusive_cond+40>, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139 +#3 0x00007f968280aa41 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55a9c1047660 <qemu_cpu_list_lock>, cond=0x55a9c1047720 <exclusive_cond>) at ./nptl/pthread_cond_wait.c:503 +#4 ___pthread_cond_wait (cond=cond@entry=0x55a9c1047720 <exclusive_cond>, mutex=mutex@entry=0x55a9c1047660 <qemu_cpu_list_lock>) at ./nptl/pthread_cond_wait.c:627 +#5 0x000055a9bff8ce9f in qemu_cond_wait_impl (cond=0x55a9c1047720 <exclusive_cond>, mutex=0x55a9c1047660 <qemu_cpu_list_lock>, file=0x55a9bffc37b6 "../cpu-common.c", line=221) at ../util/qemu-thread-posix.c:225 +#6 0x000055a9bf8fc7b7 in start_exclusive () at ../cpu-common.c:221 +#7 start_exclusive () at ../cpu-common.c:192 +#8 0x000055a9bfc2f981 in ptw_setl_slow (new=23069091, old=23069059, in=0x7f9677ffa540) at ../target/i386/tcg/sysemu/excp_helper.c:112 +#9 ptw_setl (set=<optimized out>, old=23069059, in=0x7f9677ffa540) at ../target/i386/tcg/sysemu/excp_helper.c:130 +#10 ptw_setl (set=<optimized out>, old=23069059, in=0x7f9677ffa540) at ../target/i386/tcg/sysemu/excp_helper.c:121 +#11 mmu_translate (env=env@entry=0x55a9c2ab3bc0, in=in@entry=0x7f9677ffa5f0, out=out@entry=0x7f9677ffa5c0, err=err@entry=0x7f9677ffa5d0, ra=ra@entry=140283034940586) at ../target/i386/tcg/sysemu/excp_helper.c:412 +#12 0x000055a9bfc2fe4f in get_physical_address (ra=<optimized out>, err=<optimized out>, out=<optimized out>, mmu_idx=<optimized out>, access_type=<optimized out>, addr=25041848, env=<optimized out>) at ../target/i386/tcg/sysemu/excp_helper.c:583 +#13 x86_cpu_tlb_fill (cs=0x55a9c2ab1400, addr=25041848, size=<optimized out>, access_type=MMU_DATA_LOAD, mmu_idx=5, probe=<optimized out>, retaddr=140283034940586) at ../target/i386/tcg/sysemu/excp_helper.c:603 +#14 0x000055a9bfd92a59 in tlb_fill (retaddr=140283034940586, mmu_idx=5, access_type=MMU_DATA_LOAD, size=<optimized out>, addr=25041848, cpu=0x55a9c2ab1450) at ../accel/tcg/cputlb.c:1237 +#15 mmu_lookup1 (cpu=cpu@entry=0x55a9c2ab1400, data=data@entry=0x7f9677ffa750, mmu_idx=5, access_type=access_type@entry=MMU_DATA_LOAD, ra=ra@entry=140283034940586) at ../accel/tcg/cputlb.c:1634 +#16 0x000055a9bfd92b71 in mmu_lookup (cpu=cpu@entry=0x55a9c2ab1400, addr=addr@entry=25041848, oi=oi@entry=37, ra=ra@entry=140283034940586, type=type@entry=MMU_DATA_LOAD, l=l@entry=0x7f9677ffa750) at ../accel/tcg/cputlb.c:1724 +#17 0x000055a9bfd937b0 in do_ld4_mmu (cpu=cpu@entry=0x55a9c2ab1400, addr=addr@entry=25041848, oi=oi@entry=37, ra=140283034940586, ra@entry=37, access_type=access_type@entry=MMU_DATA_LOAD) at ../accel/tcg/cputlb.c:2356 +#18 0x000055a9bfd96afa in cpu_ldl_mmu (ra=37, oi=37, addr=25041848, env=0x55a9c2ab3bc0) at ../accel/tcg/ldst_common.c.inc:160 +#19 cpu_ldl_le_mmuidx_ra (env=env@entry=0x55a9c2ab3bc0, addr=25041848, mmu_idx=mmu_idx@entry=5, ra=ra@entry=140283034940586) at ../accel/tcg/ldst_common.c.inc:298 +#20 0x000055a9bfc9a639 in popl (sa=<synthetic pointer>) at ../target/i386/tcg/seg_helper.c:88 +#21 helper_ret_protected (env=0x55a9c2ab3bc0, shift=1, is_iret=0, addend=0, retaddr=140283034940586) at ../target/i386/tcg/seg_helper.c:2031 +#22 0x00007f96307734aa in code_gen_buffer () +#23 0x000055a9bfd855f6 in cpu_tb_exec (cpu=cpu@entry=0x55a9c2ab1400, itb=itb@entry=0x7f96307733c0 <code_gen_buffer+7811987>, tb_exit=tb_exit@entry=0x7f9677ffadd8) at ../accel/tcg/cpu-exec.c:458 +#24 0x000055a9bfd85b4c in cpu_loop_exec_tb (tb_exit=0x7f9677ffadd8, last_tb=<synthetic pointer>, pc=<optimized out>, tb=0x7f96307733c0 <code_gen_buffer+7811987>, cpu=0x55a9c2ab1400) at ../accel/tcg/cpu-exec.c:908 +#25 cpu_exec_loop (cpu=cpu@entry=0x55a9c2ab1400, sc=sc@entry=0x7f9677ffae70) at ../accel/tcg/cpu-exec.c:1022 +#26 0x000055a9bfd86351 in cpu_exec_setjmp (cpu=cpu@entry=0x55a9c2ab1400, sc=sc@entry=0x7f9677ffae70) at ../accel/tcg/cpu-exec.c:1039 +#27 0x000055a9bfd86b0e in cpu_exec (cpu=cpu@entry=0x55a9c2ab1400) at ../accel/tcg/cpu-exec.c:1065 +#28 0x000055a9bfdaafa4 in tcg_cpu_exec (cpu=cpu@entry=0x55a9c2ab1400) at ../accel/tcg/tcg-accel-ops.c:78 +#29 0x000055a9bfdab0ff in mttcg_cpu_thread_fn (arg=arg@entry=0x55a9c2ab1400) at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#30 0x000055a9bff8c2d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541 +#31 0x00007f968280bac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#32 0x00007f968289d850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 + +Thread 2 (Thread 0x7f967d990640 (LWP 754759) "qemu-system-x86"): +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x000055a9bff8d5b2 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /home/user/git/qemu/include/qemu/futex.h:29 +#2 qemu_event_wait (ev=ev@entry=0x55a9c1079588 <rcu_call_ready_event>) at ../util/qemu-thread-posix.c:464 +#3 0x000055a9bff97d82 in call_rcu_thread (opaque=opaque@entry=0x0) at ../util/rcu.c:278 +#4 0x000055a9bff8c2d1 in qemu_thread_start (args=<optimized out>) at ../util/qemu-thread-posix.c:541 +#5 0x00007f968280bac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#6 0x00007f968289d850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 + +Thread 1 (Thread 0x7f967dc035c0 (LWP 754758) "qemu-system-x86"): +#0 0x00007f968288fcce in __ppoll (fds=0x55a9c382dd00, nfds=5, timeout=<optimized out>, timeout@entry=0x7ffeadbd44d0, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42 +#1 0x000055a9bffa4e05 in ppoll (__ss=0x0, __timeout=0x7ffeadbd44d0, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/poll2.h:64 +#2 qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=54822346) at ../util/qemu-timer.c:351 +#3 0x000055a9bffa1ed6 in os_host_main_loop_wait (timeout=54822346) at ../util/main-loop.c:305 +#4 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:589 +#5 0x000055a9bfb47217 in qemu_main_loop () at ../system/runstate.c:826 +#6 0x000055a9bfee421b in qemu_default_main () at ../system/main.c:37 +#7 0x00007f96827a0d90 in __libc_start_call_main (main=main@entry=0x55a9bf8f9790 <main>, argc=argc@entry=9, argv=argv@entry=0x7ffeadbd46e8) at ../sysdeps/nptl/libc_start_call_main.h:58 +#8 0x00007f96827a0e40 in __libc_start_main_impl (main=0x55a9bf8f9790 <main>, argc=9, argv=0x7ffeadbd46e8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffeadbd46d8) at ../csu/libc-start.c:392 +#9 0x000055a9bf8fa7b5 in _start () +``` diff --git a/results/classifier/gemma3:12b/debug/2580 b/results/classifier/gemma3:12b/debug/2580 new file mode 100644 index 000000000..9ad5a96c4 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2580 @@ -0,0 +1,13 @@ + +qemu-aarch64_be 9.1.0 fails to run any Linux programs due to unreachable in gdb_find_static_feature() +Description of problem: +``` +❯ cat empty.c +void _start() {} +❯ clang empty.c -target aarch64_be-linux -nostdlib -fuse-ld=lld +❯ qemu-aarch64_be ./a.out +** +ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached +Bail out! ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached +fish: Job 1, 'qemu-aarch64_be ./a.out' terminated by signal SIGABRT (Abort) +``` diff --git a/results/classifier/gemma3:12b/debug/2590 b/results/classifier/gemma3:12b/debug/2590 new file mode 100644 index 000000000..318050016 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2590 @@ -0,0 +1,24 @@ + +qemu-x86_64: gdb doesn't read symbols from dynamically linked shared libraries. +Description of problem: +GDB fails to load dynamically linked shared libraries when connecting to qemu-x86_64, causing it to not recognize symbols from the shared libraries. As a result, breakpoints in shared library functions (e.g, `break printf`) do not work. +Steps to reproduce: +1. Start the debug server: `./qemu-x86_64 -g PORT ./x86_64-binary` +2. Connect GDB to the debug server: +``` +$ gdb-multiarch ./x86_64-binary +(gdb) set verbose on +(gdb) target remote :PORT +``` +3. GDB displays a warning and fails to load shared libraries: +``` +(gdb) target remote :PORT +Remote debugging using :PORT +warning: platform-specific solib_create_inferior_hook did not load initial shared libraries. +(gdb) info sharedlibrary +No shared libraries loaded at this time. +``` +Additional information: +This issue does not occur when using gdbserver on a native x86_64 machine and connecting to it from gdb-multiarch on an ARM64 machine, indicating the issue is likely related to QEMU rather than GDB. + +GDB correctly recognizes symbols from the target binary (e.g., the `main` function), and breakpoints at these symbols function as expected. diff --git a/results/classifier/gemma3:12b/debug/2601 b/results/classifier/gemma3:12b/debug/2601 new file mode 100644 index 000000000..1e7a8b781 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2601 @@ -0,0 +1,37 @@ + +Executing LD1SB + MTE on Arm64 fails an assert +Description of problem: +I'm getting +``` +qemu-system-aarch64: ../tcg/tcg-op-gvec.c:91: simd_desc: Assertion `data == sextract32(data, 0, (32 - ((0 + 8) + 2)))' failed. +``` +This is caused by the upper bits of `data` being set to 1, which violates the condition. +Steps to reproduce: +1. build QEMU with assertions enabled (e.g., `configure --enable-debug-tcg`). +2. have a `LD1SB f{z25.d}, p3/z, [x14, x9]` (binary a5894dd9) instruction in the executed code. +3. enable mte +4. Let QEMU execute the ld1sb instruction. +Additional information: +{width=699 height=141} + +This issue happens because for ld1sb, nregs=0 in `sve.decode`: +``` +# SVE contiguous load (scalar plus scalar) +LD_zprr 1010010 .... ..... 010 ... ..... ..... @rprr_load_dt nreg=0 +``` +As a result, in do_mem_zpa is called with n_reg=0, which becomes mte_n inside do_mem_zpa. +Since mte_n==0, and mte_active, then +```c +desc = FIELD_DP32(desc, MTEDESC, SIZEM1, (mte_n << msz) - 1); +``` +sets (0) - 1 == -1 to the field, which also sets the upper bits of `desc`. +The `desc` with upper bits set to 1 is used to call: +```c +desc = simd_desc(vsz, vsz, zt | desc); +``` +Inside `simd_desc`, the last parameter is named `data` and it fails the assertion: +```c +tcg_debug_assert(data == sextract32(data, 0, SIMD_DATA_BITS)) +``` + +# diff --git a/results/classifier/gemma3:12b/debug/2633 b/results/classifier/gemma3:12b/debug/2633 new file mode 100644 index 000000000..be96e7fc8 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2633 @@ -0,0 +1,27 @@ + +migration-test occassionally hangs with "Failed to peek at channel" +Description of problem: +Running the 'migration-test' qtest in a loop, eventually resulted in a hang. + +``` +# Running /x86_64/migration/multifd/tcp/plain/cancel +# Using machine type: pc-q35-9.2 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-75145.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-75145.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.2, -name source,debug-threads=on -m 150M -serial file:/tmp/migration-test-DJLYV2/src_serial -drive if=none,id=d0,file=/tmp/migration-test-DJLYV2/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-75145.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-75145.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.2, -name target,debug-threads=on -m 150M -serial file:/tmp/migration-test-DJLYV2/dest_serial -incoming defer -drive if=none,id=d0,file=/tmp/migration-test-DJLYV2/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 2>/dev/null -accel qtest +# Using machine type: pc-q35-9.2 +# starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-75145.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-75145.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -accel kvm -accel tcg -machine pc-q35-9.2, -name target,debug-threads=on -m 150M -serial file:/tmp/migration-test-DJLYV2/dest_serial -incoming defer -drive if=none,id=d0,file=/tmp/migration-test-DJLYV2/bootsect,format=raw -device ide-hd,drive=d0,secs=1,cyls=1,heads=1 -accel qtest +qemu-system-x86_64: Failed to peek at channel +....hang here.... +``` +Steps to reproduce: +In host run + +``` +make vm-build-openbsd DEBUG=1' +``` +when it is done and gives a shell account then run + +1. `cd /home/qemu/qemu-test.*/build` +2. `export QTEST_QEMU_BINARY=./qemu-system-x86_64` +3. `while true ; do ./tests/qtest/migration-test ; done` +4. ....wait some time until it shows the above hang.... diff --git a/results/classifier/gemma3:12b/debug/2687 b/results/classifier/gemma3:12b/debug/2687 new file mode 100644 index 000000000..86adb2dfa --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2687 @@ -0,0 +1,50 @@ + +regression in qtest clock_set/clock_step +Description of problem: +As of QEMU 9.0 the script included below would increment the time via qtest, but it is now broken and time doesn't seem to be updated. I do note that the QEMU sources use clock_step extensively via qtest_clock_step, but nothing seems to be using the return value so maybe that's why it hasn't been noticed? + +It seems to have been broken in bc02be4508d8753d1f6071b77d10f4661587df6f which was trying to prevent some deadlock. You can prove that this breaks it by setting a breakpoint in `qemu_virtual_clock_set_ns` -- it never gets called. +Steps to reproduce: +Run this python script from your QEMU build directory: + +```python +#!/usr/bin/env python3 + +import subprocess +import socket +import typing + +qemu_path = "./qemu-system-x86_64" + + +def main(): + s1, s2 = socket.socketpair() + + qemu = subprocess.Popen( + [ + qemu_path, + "-S", + "-display", + "none", + "-chardev", f"socket,id=qtest,fd={s1.fileno()},nodelay=on", + "-qtest", "chardev:qtest", + "-qtest-log", "/dev/fd/2", + "-accel", "qtest", + ], + pass_fds=[s1.fileno()], + ) + + try: + + fp = s2.makefile("rw", buffering=1) + + fp.write(f"clock_set 1234\n") + result = fp.readline()[:-1].split(" ") + assert result == ["OK", "1234"], f"Unexpected result: {result}" + finally: + qemu.kill() + + +if __name__ == "__main__": + main() +``` diff --git a/results/classifier/gemma3:12b/debug/2697 b/results/classifier/gemma3:12b/debug/2697 new file mode 100644 index 000000000..65ba96a59 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2697 @@ -0,0 +1,2 @@ + +system/physmem: gdb memory rw no access on armv7m MPU diff --git a/results/classifier/gemma3:12b/debug/2736 b/results/classifier/gemma3:12b/debug/2736 new file mode 100644 index 000000000..0f1b81de9 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2736 @@ -0,0 +1,11 @@ + +assert_fail in vmstate_load_state (icount related) +Description of problem: +qemu crashes with an assert failure. +Steps to reproduce: +- Run qemu-system-sparc with "-i count auto -rtc clock=vm" + - Create a snapshot. Exit qemu. + - Run qemu-system-sparc without "-i count auto -rtc clock-vm" + - Try to load the snapshot via the monitor +Additional information: +[gdb.out](/uploads/d08539ce9eb6b599918513e279f13453/gdb.out) diff --git a/results/classifier/gemma3:12b/debug/2750 b/results/classifier/gemma3:12b/debug/2750 new file mode 100644 index 000000000..e80bc14fe --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2750 @@ -0,0 +1,12 @@ + +Data race in the goflag global variable in the rcutorture test. +Description of problem: +A data race involving the `goflag` global variable in `tests/unit/rcutorture.c` was identified using TSAN. +Steps to reproduce: +```sh +QEMU_BUILD_DIR=<path to the QEMU build directory> +QEMU_DIR=<path to the QEMU repository directory> +configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp +make tests/unit/rcutorture +MALLOC_PERTURB_=194 G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_SRCDIR=$QEMU_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/rcutorture --tap -k +``` diff --git a/results/classifier/gemma3:12b/debug/2751 b/results/classifier/gemma3:12b/debug/2751 new file mode 100644 index 000000000..8812b65f8 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2751 @@ -0,0 +1,2 @@ + +QEMU user emulation gdbstub emits incorrect file descriptor and errno values diff --git a/results/classifier/gemma3:12b/debug/2760 b/results/classifier/gemma3:12b/debug/2760 new file mode 100644 index 000000000..ba6ead57b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2760 @@ -0,0 +1,2 @@ + +Some Aarch64 system registers not available via the debugger diff --git a/results/classifier/gemma3:12b/debug/2790 b/results/classifier/gemma3:12b/debug/2790 new file mode 100644 index 000000000..2f3fa1e4a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2790 @@ -0,0 +1,11 @@ + +Can't switch to monitor with rr=record +Description of problem: +With the above args, while the guest is paused (either because I haven't attached GDB yet, or because I've halted execution in GDB), it's not possible to switch to the QEMU monitor. + +I don't reproduce this issue with `QEMU emulator version 8.2.4 (Debian 1:8.2.4+ds-1+build1)` but I do with 9.2 and master (built from source). + +AFAICT, the monitor is working - if I just set `-monitor stdio` instead of `-serial mon:stdio` I can use it, including when the VM is paused. But the multiplexing doesn't work. +Steps to reproduce: +1. Run the above +2. Ctrl-A, c diff --git a/results/classifier/gemma3:12b/debug/2791 b/results/classifier/gemma3:12b/debug/2791 new file mode 100644 index 000000000..b01153c97 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2791 @@ -0,0 +1,64 @@ + +"Missing character write event in the replay log" when trying rr=replay with snapshot +Description of problem: +Probably best to just illustrate with commands. Happy path: + +```sh +rm replay.bin snapshots.qcow2; qemu-img create -f qcow2 snapshots.qcow2 256M + +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -serial stdio \ + -icount shift=auto,rr=record,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" + +# It runs, guest kernel crashes when realising it has no rootfs, all good +du -sh snapshots.qcow2 # 976K + +# Repeat same command just switched to rr=replay +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -serial stdio \ + -icount shift=auto,rr=replay,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" +# Much slower, but same result. All good +``` + +But, I want to take a snapshot later in boot. + +```sh +rm replay.bin snapshots.qcow2; qemu-img create -f qcow2 snapshots.qcow2 256M + +# This time, running with debug. Also have to switch to -monitor stdio because of +# https://gitlab.com/qemu-project/qemu/-/issues/2790 +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -monitor stdio \ + -icount shift=auto,rr=record,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" \ + -s -S + +# In another terminal, attach a debugger, set a breakpoint, continue to the breakpoint +gdb -ex "target remote localhost:1234" .kunit/vmlinux +(gdb) hb start_kernel +(gdb) continue + +# When the breakpoint is hit, back in the first terminal: +(qemu) savevm test +(qemu) quit + +du -sh snapshots.qcow2 # 21M + +# Now try to replay again +~/src/qemu/build/qemu-system-x86_64 -nodefaults -nographic -serial stdio \ + -icount shift=auto,rr=replay,rrfile=replay.bin,rrsnapshot=init \ + -drive file=snapshots.qcow2,if=none,id=rr \ + -kernel ./.kunit/arch/x86/boot/bzImage -append "nokaslr console=ttyS0" +``` + +Result: + +``` +qemu-system-x86_64: Missing character write event in the replay log (insn total 1598039/586 left, event 886 is EVENT_INSTRUCTION) +fish: Job 1, '~/src/qemu/build/qemu-system-x8…' terminated by signal -icount shift=auto,rr=repla… ( -drive file=snapshots.qcow2…) +fish: Job -kernel ./.kunit/arch/x86/b…, 'SIGABRT' terminated by signal Abort () +``` + +Exit code is 134. diff --git a/results/classifier/gemma3:12b/debug/2793 b/results/classifier/gemma3:12b/debug/2793 new file mode 100644 index 000000000..c47adbd0b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2793 @@ -0,0 +1,243 @@ + +Upgrading from qemu-kvm-* (17:9.1.0-7.el9) to (17:9.1.0-9.el9) causes VM to crash within cockpit-machines (v326-1.el9) with qemu-kvm: ../qapi/qobject-output-visitor.c:95: void qobject_output_add_obj(QObjectOutputVisitor *, const char *, QObject *): Assert +Description of problem: +** From the /var/log/libvirt/qemu/WinDesktop03-log ** + +2025-01-21 21:50:57.464+0000: Starting external device: TPM Emulator +/usr/bin/swtpm socket --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/1-WinDesktop-03-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/fb44aa6f-8127-4df7-afc3-2ba54b7b7790/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt/qemu/WinDesktop-03-swtpm.log --terminate --tpm2 +2025-01-21 21:50:57.501+0000: starting up libvirt version: 10.10.0, package: 3.el9 (builder@centos.org, 2024-12-20-13:49:58, ), qemu version: 9.1.0qemu-kvm-9.1.0-7.el9, kernel: 6.12.9, hostname: amd-strat-3 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-1-WinDesktop-03 \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-1-WinDesktop-03/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-1-WinDesktop-03/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-1-WinDesktop-03/.config \ +/usr/libexec/qemu-kvm \ +-name guest=WinDesktop-03,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-1-WinDesktop-03/master-key.aes"}' \ +-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/WinDesktop-03_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \ +-machine pc-q35-rhel9.6.0,usb=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,hpet=off,acpi=on \ +-accel kvm \ +-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff,hv-vpindex=on,hv-runtime=on,hv-synic=on,hv-stimer=on,hv-frequencies=on,hv-tlbflush=on,hv-ipi=on,hv-avic=on \ +-global driver=cfi.pflash01,property=secure,value=on \ +-m size=8388608k \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592}' \ +-overcommit mem-lock=off \ +-smp 8,sockets=1,dies=1,clusters=1,cores=8,threads=1 \ +-uuid fb44aa6f-8127-4df7-afc3-2ba54b7b7790 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=23,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ +-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \ +-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \ +-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \ +-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \ +-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \ +-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \ +-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \ +-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \ +-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \ +-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \ +-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \ +-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \ +-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \ +-device '{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.2","addr":"0x0"}' \ +-device '{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.4","addr":"0x0"}' \ +-blockdev '{"driver":"file","filename":"/stratistor/clustermounts/machines/WinDesktop-03/WinDesktop-03.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":1}' \ +-netdev '{"type":"tap","fd":"25","vhost":true,"vhostfd":"27","id":"hostnet0"}' \ +-device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:d4:af:c9","bus":"pci.1","addr":"0x0"}' \ +-chardev pty,id=charserial0 \ +-device '{"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0}' \ +-chardev socket,id=charchannel0,fd=22,server=on,wait=off \ +-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \ +-chardev socket,id=chrtpm,path=/run/libvirt/qemu/swtpm/1-WinDesktop-03-swtpm.sock \ +-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \ +-device '{"driver":"tpm-crb","tpmdev":"tpm-tpm0","id":"tpm0"}' \ +-device '{"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-vnc 0.0.0.0:0,audiodev=audio1 \ +-device '{"driver":"virtio-vga","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"}' \ +-global ICH9-LPC.noreboot=off \ +-watchdog-action reset \ +-incoming defer \ +-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.3","addr":"0x0"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2025-01-21 21:50:57.502+0000: Domain id=1 is tainted: high-privileges +2025-01-21 21:50:57.502+0000: Domain id=1 is tainted: host-cpu +char device redirected to /dev/pts/0 (label charserial0) +2025-01-21 21:51:07.797+0000: Domain id=1 is tainted: custom-ga-command +2025-01-25T20:54:12.923119Z qemu-kvm: terminating on signal 15 from pid 279229 (/usr/sbin/virtqemud) +2025-01-25 20:54:13.215+0000: shutting down, reason=shutdown +2025-01-25 20:54:18.392+0000: Starting external device: TPM Emulator +/usr/bin/swtpm socket --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/2-WinDesktop-03-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/fb44aa6f-8127-4df7-afc3-2ba54b7b7790/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt/qemu/WinDesktop-03-swtpm.log --terminate --tpm2 +2025-01-25 20:54:18.414+0000: starting up libvirt version: 10.10.0, package: 3.el9 (builder@centos.org, 2024-12-20-13:49:58, ), qemu version: 9.1.0qemu-kvm-9.1.0-9.el9, kernel: 6.12.9, hostname: amd-strat-3 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-2-WinDesktop-03 \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-2-WinDesktop-03/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-2-WinDesktop-03/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-2-WinDesktop-03/.config \ +/usr/libexec/qemu-kvm \ +-name guest=WinDesktop-03,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-2-WinDesktop-03/master-key.aes"}' \ +-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/WinDesktop-03_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \ +-machine pc-q35-rhel9.6.0,usb=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,hpet=off,acpi=on \ +-accel kvm \ +-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff,hv-vpindex=on,hv-runtime=on,hv-synic=on,hv-stimer=on,hv-frequencies=on,hv-tlbflush=on,hv-ipi=on,hv-avic=on \ +-global driver=cfi.pflash01,property=secure,value=on \ +-m size=8388608k \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592}' \ +-overcommit mem-lock=off \ +-smp 8,sockets=1,dies=1,clusters=1,cores=8,threads=1 \ +-uuid fb44aa6f-8127-4df7-afc3-2ba54b7b7790 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=25,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ +-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \ +-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \ +-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \ +-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \ +-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \ +-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \ +-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \ +-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \ +-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \ +-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \ +-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \ +-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \ +-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \ +-device '{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.2","addr":"0x0"}' \ +-device '{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.4","addr":"0x0"}' \ +-blockdev '{"driver":"file","filename":"/stratistor/clustermounts/machines/WinDesktop-03/WinDesktop-03.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":1}' \ +-netdev '{"type":"tap","fd":"27","vhost":true,"vhostfd":"34","id":"hostnet0"}' \ +-device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:d4:af:c9","bus":"pci.1","addr":"0x0"}' \ +-chardev pty,id=charserial0 \ +-device '{"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0}' \ +-chardev socket,id=charchannel0,fd=23,server=on,wait=off \ +-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \ +-chardev socket,id=chrtpm,path=/run/libvirt/qemu/swtpm/2-WinDesktop-03-swtpm.sock \ +-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \ +-device '{"driver":"tpm-crb","tpmdev":"tpm-tpm0","id":"tpm0"}' \ +-device '{"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-vnc 0.0.0.0:0,audiodev=audio1 \ +-device '{"driver":"virtio-vga","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"}' \ +-global ICH9-LPC.noreboot=off \ +-watchdog-action reset \ +-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.3","addr":"0x0"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2025-01-25 20:54:18.414+0000: Domain id=2 is tainted: high-privileges +char device redirected to /dev/pts/0 (label charserial0) +qemu-kvm: ../qapi/qobject-output-visitor.c:95: void qobject_output_add_obj(QObjectOutputVisitor *, const char *, QObject *): Assertion `name' failed. +2025-01-25 20:54:19.395+0000: shutting down, reason=crashed +2025-01-25 20:54:25.221+0000: Starting external device: TPM Emulator +/usr/bin/swtpm socket --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/3-WinDesktop-03-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/fb44aa6f-8127-4df7-afc3-2ba54b7b7790/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt/qemu/WinDesktop-03-swtpm.log --terminate --tpm2 +2025-01-25 20:54:25.242+0000: starting up libvirt version: 10.10.0, package: 3.el9 (builder@centos.org, 2024-12-20-13:49:58, ), qemu version: 9.1.0qemu-kvm-9.1.0-9.el9, kernel: 6.12.9, hostname: amd-strat-3 +LC_ALL=C \ +PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +HOME=/var/lib/libvirt/qemu/domain-3-WinDesktop-03 \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-3-WinDesktop-03/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-3-WinDesktop-03/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-3-WinDesktop-03/.config \ +/usr/libexec/qemu-kvm \ +-name guest=WinDesktop-03,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-3-WinDesktop-03/master-key.aes"}' \ +-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/WinDesktop-03_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \ +-machine pc-q35-rhel9.6.0,usb=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,hpet=off,acpi=on \ +-accel kvm \ +-cpu host,migratable=on,hv-time=on,hv-relaxed=on,hv-vapic=on,hv-spinlocks=0x1fff,hv-vpindex=on,hv-runtime=on,hv-synic=on,hv-stimer=on,hv-frequencies=on,hv-tlbflush=on,hv-ipi=on,hv-avic=on \ +-global driver=cfi.pflash01,property=secure,value=on \ +-m size=8388608k \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592}' \ +-overcommit mem-lock=off \ +-smp 8,sockets=1,dies=1,clusters=1,cores=8,threads=1 \ +-uuid fb44aa6f-8127-4df7-afc3-2ba54b7b7790 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=25,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=localtime,driftfix=slew \ +-global kvm-pit.lost_tick_policy=delay \ +-no-shutdown \ +-global ICH9-LPC.disable_s3=1 \ +-global ICH9-LPC.disable_s4=1 \ +-boot strict=on \ +-device '{"driver":"pcie-root-port","port":16,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ +-device '{"driver":"pcie-root-port","port":17,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x2.0x1"}' \ +-device '{"driver":"pcie-root-port","port":18,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x2.0x2"}' \ +-device '{"driver":"pcie-root-port","port":19,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x2.0x3"}' \ +-device '{"driver":"pcie-root-port","port":20,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x2.0x4"}' \ +-device '{"driver":"pcie-root-port","port":21,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x2.0x5"}' \ +-device '{"driver":"pcie-root-port","port":22,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x2.0x6"}' \ +-device '{"driver":"pcie-root-port","port":23,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x2.0x7"}' \ +-device '{"driver":"pcie-root-port","port":24,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x3"}' \ +-device '{"driver":"pcie-root-port","port":25,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x3.0x1"}' \ +-device '{"driver":"pcie-root-port","port":26,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x3.0x2"}' \ +-device '{"driver":"pcie-root-port","port":27,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x3.0x3"}' \ +-device '{"driver":"pcie-root-port","port":28,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x3.0x4"}' \ +-device '{"driver":"pcie-root-port","port":29,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x3.0x5"}' \ +-device '{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.2","addr":"0x0"}' \ +-device '{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.4","addr":"0x0"}' \ +-blockdev '{"driver":"file","filename":"/stratistor/clustermounts/machines/WinDesktop-03/WinDesktop-03.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +-device '{"driver":"ide-hd","bus":"ide.0","drive":"libvirt-1-format","id":"sata0-0-0","bootindex":1}' \ +-netdev '{"type":"tap","fd":"27","vhost":true,"vhostfd":"34","id":"hostnet0"}' \ +-device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:d4:af:c9","bus":"pci.1","addr":"0x0"}' \ +-chardev pty,id=charserial0 \ +-device '{"driver":"isa-serial","chardev":"charserial0","id":"serial0","index":0}' \ +-chardev socket,id=charchannel0,fd=23,server=on,wait=off \ +-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \ +-chardev socket,id=chrtpm,path=/run/libvirt/qemu/swtpm/3-WinDesktop-03-swtpm.sock \ +-tpmdev emulator,id=tpm-tpm0,chardev=chrtpm \ +-device '{"driver":"tpm-crb","tpmdev":"tpm-tpm0","id":"tpm0"}' \ +-device '{"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-vnc 0.0.0.0:0,audiodev=audio1 \ +-device '{"driver":"virtio-vga","id":"video0","max_outputs":1,"bus":"pcie.0","addr":"0x1"}' \ +-global ICH9-LPC.noreboot=off \ +-watchdog-action reset \ +-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.3","addr":"0x0"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +2025-01-25 20:54:25.242+0000: Domain id=3 is tainted: high-privileges +char device redirected to /dev/pts/0 (label charserial0) +**qemu-kvm: ../qapi/qobject-output-visitor.c:95: void qobject_output_add_obj(QObjectOutputVisitor *, const char *, QObject *): Assertion `name' failed. +2025-01-25 20:54:29.967+0000: shutting down, reason=crashed** +Steps to reproduce: +1. Could not produce crash with qemu version 9.1.0-7, upgraded to 9.1.0-9. +2. Started VM using cockpit web interface +3. Crashes within 5 seconds of starting +4. Opening a ticket with cockpit-machines tracker as well as this only happens in cockpit-machines. I am able to open console using virt-manager without crashing, it's only with the cockpit-machines web interface on the VM summary page for the specific VM that appears to cause this. +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/2814 b/results/classifier/gemma3:12b/debug/2814 new file mode 100644 index 000000000..beddf3f71 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2814 @@ -0,0 +1,2 @@ + +Convert gdb_core_xml_file to function for https://linaro.atlassian.net/browse/QEMU-487 diff --git a/results/classifier/gemma3:12b/debug/2830 b/results/classifier/gemma3:12b/debug/2830 new file mode 100644 index 000000000..ff1126a46 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2830 @@ -0,0 +1,2 @@ + +gdbstub: breakpoint/watchpoint increments warp timer on single-core icount mode, breaking determinism diff --git a/results/classifier/gemma3:12b/debug/2831 b/results/classifier/gemma3:12b/debug/2831 new file mode 100644 index 000000000..9c9ac46f1 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2831 @@ -0,0 +1,21 @@ + +unable to build on Sequoia 15.3 +Description of problem: + +Steps to reproduce: +1. git clone https://gitlab.com/qemu-project/qemu.git +2. ../configure --target-list=riscv32-softmmu --enable-debug +3. make + +Error: +ld: multiple errors: archive member '/' not a mach-o file in '../qemu/build/subprojects/dtc/libfdt/libfdt.a'; archive member '/' not a mach-o file in '../qemu/build/libqemuutil.a' +Additional information: +I tried the more detailed "build for macos" instructions +./configure --cc=clang-7 --cxx=clang++-7 --host-cc=clang-7 \ +--extra-cflags=-mavx2 \ +--extra-cxxflags="-I/usr/local/opt/llvm/include" \ +--extra-ldflags="-L/usr/local/opt/llvm/lib -L/usr/local/opt/libffi/lib -L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib" \ +--target-list="<list of machines here>" + +but this didn't work for any version of clang I tried, giving me the error in all cases: +ERROR: C compiler "clang-xxx" either does not exist or does not work. diff --git a/results/classifier/gemma3:12b/debug/2857 b/results/classifier/gemma3:12b/debug/2857 new file mode 100644 index 000000000..2a74985fe --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2857 @@ -0,0 +1,101 @@ + +segmentation fault issue in qemu-option.c for both qemu-system-x86_64 and qemu-system-aarch64 +Description of problem: + +Steps to reproduce: +1. Compile with; +``` +| PKG_CONFIG_PATH="$PWD/../../lib/pkgconfig" ../../source/qemu-9.2.1/configure \ | +|------------------------------------------------------------------------------------| +| --extra-cflags="-I$PWD/../../source/angle/include -march=armv8-a+crc+crypto" \ | +| --extra-ldflags="-L$PWD/../angle" \ | +| --disable-cocoa \ | +| --enable-sdl \ | +| --prefix="$PWD/../.." | +``` +2.`./bin/qemu-system-aarch64 -machine virt,accel=hvf -cpu host` +3. Single liner for building: +``` +curl -L https://gist.github.com/startergo/0d9a7425876c2b42f8b797af80fbe3d8/raw/run-arm-3dfx-sdl.sh | bash - +``` +Additional information: +``` + +lldb -- ./bin/qemu-system-aarch64 -machine virt,accel=hvf -cpu host +(lldb) target create "./bin/qemu-system-aarch64" +Current executable set to '/Users/macbookpro/Downloads/qemu-3dfx-arch/bin/qemu-system-aarch64' (arm64). +(lldb) settings set -- target.run-args "-machine" "virt,accel=hvf" "-cpu" "host" +(lldb) run +Process 64856 launched: '/Users/macbookpro/Downloads/qemu-3dfx-arch/bin/qemu-system-aarch64' (arm64) +Process 64856 stopped +* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGUSR2 + frame #0: 0x0000000199d78cc0 libsystem_kernel.dylib`__sigsuspend + 8 +libsystem_kernel.dylib`__sigsuspend: +-> 0x199d78cc0 <+8>: b.lo 0x199d78ce0 ; <+40> + 0x199d78cc4 <+12>: pacibsp + 0x199d78cc8 <+16>: stp x29, x30, [sp, #-0x10]! + 0x199d78ccc <+20>: mov x29, sp +Target 0: (qemu-system-aarch64) stopped. +(lldb) continue +Process 64856 resuming +Process 64856 stopped +* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) + frame #0: 0x0000000000000000 +error: memory read failed for 0x0 +Target 0: (qemu-system-aarch64) stopped. +(lldb) bt +* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) + * frame #0: 0x0000000000000000 + frame #1: 0x00000001008539ec qemu-system-aarch64`get_opt_name_value [inlined] qemu_strchrnul(s="nic", c=44) at cutils.h:144:12 [opt] + frame #2: 0x00000001008539e0 qemu-system-aarch64`get_opt_name_value [inlined] get_opt_value(p="nic", value=0x000000016fdff058) at qemu-option.c:71:18 [opt] + frame #3: 0x00000001008539dc qemu-system-aarch64`get_opt_name_value(params=<unavailable>, firstname=<unavailable>, warn_on_flag=<unavailable>, help_wanted=0x0000000000000000, name=<unavailable>, value=0x000000016fdff058) at qemu-option.c:760:17 [opt] + frame #4: 0x0000000100853c84 qemu-system-aarch64`opts_do_parse(opts=0x0000600002e30460, params="nic", firstname=<unavailable>, warn_on_flag=false, help_wanted=0x0000000000000000, errp=0x00000001018fd500) at qemu-option.c:808:13 [opt] + frame #5: 0x0000000100853fbc qemu-system-aarch64`opts_parse(list=<unavailable>, params="nic", permit_abbrev=<unavailable>, warn_on_flag=false, help_wanted=0x0000000000000000, errp=0x00000001018fd500) at qemu-option.c:898:10 [opt] + frame #6: 0x0000000100853ea0 qemu-system-aarch64`qemu_opts_parse(list=<unavailable>, params=<unavailable>, permit_abbrev=<unavailable>, errp=<unavailable>) at qemu-option.c:917:12 [opt] [artificial] + frame #7: 0x00000001002937b4 qemu-system-aarch64`qemu_init [inlined] qemu_create_default_devices at vl.c:1446:9 [opt] + frame #8: 0x0000000100293640 qemu-system-aarch64`qemu_init(argc=<unavailable>, argv=0x000000016fdff500) at vl.c:3692:5 [opt] + frame #9: 0x00000001007b58c0 qemu-system-aarch64`main(argc=<unavailable>, argv=<unavailable>) at main.c:47:5 [opt] + frame #10: 0x0000000199a2c274 dyld`start + 2840 + +lldb -- ./bin/qemu-system-x86_64 -machine q35,accel=hvf -cpu host +(lldb) target create "./bin/qemu-system-x86_64" +Current executable set to '/Users/macbookpro/Downloads/qemu-3dfx-arch/bin/qemu-system-x86_64' (arm64). +(lldb) settings set -- target.run-args "-machine" "q35,accel=hvf" "-cpu" "host" +(lldb) run +Process 65669 launched: '/Users/macbookpro/Downloads/qemu-3dfx-arch/bin/qemu-system-x86_64' (arm64) +Process 65669 stopped +* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGUSR2 + frame #0: 0x0000000199d78cc0 libsystem_kernel.dylib`__sigsuspend + 8 +libsystem_kernel.dylib`__sigsuspend: +-> 0x199d78cc0 <+8>: b.lo 0x199d78ce0 ; <+40> + 0x199d78cc4 <+12>: pacibsp + 0x199d78cc8 <+16>: stp x29, x30, [sp, #-0x10]! + 0x199d78ccc <+20>: mov x29, sp +Target 0: (qemu-system-x86_64) stopped. +(lldb) continue +Process 65669 resuming +Process 65669 stopped +* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) + frame #0: 0x0000000000000000 +error: memory read failed for 0x0 +Target 0: (qemu-system-x86_64) stopped. +(lldb) bt +* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) + * frame #0: 0x0000000000000000 + frame #1: 0x000000010053c7f0 qemu-system-x86_64`get_opt_name_value [inlined] qemu_strchrnul(s="nic", c=44) at cutils.h:144:12 [opt] + frame #2: 0x000000010053c7e4 qemu-system-x86_64`get_opt_name_value [inlined] get_opt_value(p="nic", value=0x000000016fdff058) at qemu-option.c:71:18 [opt] + frame #3: 0x000000010053c7e0 qemu-system-x86_64`get_opt_name_value(params=<unavailable>, firstname=<unavailable>, warn_on_flag=<unavailable>, help_wanted=0x0000000000000000, name=<unavailable>, value=0x000000016fdff058) at qemu-option.c:760:17 [opt] + frame #4: 0x000000010053ca88 qemu-system-x86_64`opts_do_parse(opts=0x0000600002476ee0, params="nic", firstname=<unavailable>, warn_on_flag=false, help_wanted=0x0000000000000000, errp=0x00000001014fa230) at qemu-option.c:808:13 [opt] + frame #5: 0x000000010053cdc0 qemu-system-x86_64`opts_parse(list=<unavailable>, params="nic", permit_abbrev=<unavailable>, warn_on_flag=false, help_wanted=0x0000000000000000, errp=0x00000001014fa230) at qemu-option.c:898:10 [opt] + frame #6: 0x000000010053cca4 qemu-system-x86_64`qemu_opts_parse(list=<unavailable>, params=<unavailable>, permit_abbrev=<unavailable>, errp=<unavailable>) at qemu-option.c:917:12 [opt] [artificial] + frame #7: 0x00000001001d6b00 qemu-system-x86_64`qemu_init [inlined] qemu_create_default_devices at vl.c:1446:9 [opt] + frame #8: 0x00000001001d698c qemu-system-x86_64`qemu_init(argc=<unavailable>, argv=0x000000016fdff500) at vl.c:3692:5 [opt] + frame #9: 0x000000010049e7c0 qemu-system-x86_64`main(argc=<unavailable>, argv=<unavailable>) at main.c:47:5 [opt] + frame #10: 0x0000000199a2c274 dyld`start + 2840 + +--> + +``` +The line below ensures that proper tags are added to the issue. +Please do not remove it. +--> diff --git a/results/classifier/gemma3:12b/debug/2895 b/results/classifier/gemma3:12b/debug/2895 new file mode 100644 index 000000000..1475d5400 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2895 @@ -0,0 +1,31 @@ + +qemu-system-aarch64: Error: r = HV_BAD_ARGUMENT (0xfae94003, at ../target/arm/hvf/hvf.c:2259) +Description of problem: +When I launch a Linux guest in QEMU with `-accel hvf` + `-gdb "tcp::1234"`, and I try to debug the kernel with `lldb`, QEMU crashes with the following report: + +``` +qemu-system-aarch64: Error: r = HV_BAD_ARGUMENT (0xfae94003, at ../target/arm/hvf/hvf.c:2259) +``` +Steps to reproduce: +1. Run QEMU with `-accel hvf` + `-gdb "tcp::1234"` and a custom kernel (`-kernel Image`) +2. Try to attach using `lldb vmlinux` + `(lldb) gdb-remote 1234` +Additional information: +Debugging QEMU I see the crash is due to the `cpu->accel->fd` file descriptor being `0`: + +``` +warning: qemu-system-aarch64 was compiled with optimization - stepping may behave oddly; variables may not be available. +frame #4: 0x00000001003dd24c qemu-system-aarch64`hvf_arch_update_guest_debug [inlined] hvf_put_guest_debug_registers(cpu=0x0000000158118000) at hvf.c:2259:9 [opt] + 2256 for (i = 0; i < max_hw_bps; i++) { + 2257 r = hv_vcpu_set_sys_reg(cpu->accel->fd, dbgbcr_regs[i], + 2258 env->cp15.dbgbcr[i]); +-> 2259 assert_hvf_ok(r); + 2260 r = hv_vcpu_set_sys_reg(cpu->accel->fd, dbgbvr_regs[i], + 2261 env->cp15.dbgbvr[i]); + 2262 assert_hvf_ok(r); +(lldb) print cpu->accel->fd +(hvf_vcpuid) 0 +(lldb) print dbgbcr_regs[i] +(const uint16_t) 32773 +(lldb) print env->cp15.dbgbcr[i] +(uint64_t) 480 +``` diff --git a/results/classifier/gemma3:12b/debug/2903 b/results/classifier/gemma3:12b/debug/2903 new file mode 100644 index 000000000..cfc6b9176 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2903 @@ -0,0 +1,12 @@ + +Data Race in assertion in aio-posix.c +Description of problem: +Potential data races in the assertion in `test-aio-multithread` were identified using TSAN. +Steps to reproduce: +```sh +QEMU_BUILD_DIR=<path to the QEMU build directory> +QEMU_DIR=<path to the QEMU repository directory> +configure --enable-tsan --cc=clang --cxx=clang++ --enable-trace-backends=ust --enable-fdt=system --disable-slirp +make tests/unit/test-bdrv-drain +MALLOC_PERTURB_=102 G_TEST_SRCDIR=$QEMU_BUILD_DIR/tests/unit G_TEST_BUILDDIR=$QEMU_BUILD_DIR/tests/unit $QEMU_BUILD_DIR/tests/unit/test-aio-multithread --tap -k +``` diff --git a/results/classifier/gemma3:12b/debug/2921 b/results/classifier/gemma3:12b/debug/2921 new file mode 100644 index 000000000..ddfac5350 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2921 @@ -0,0 +1,369 @@ + +Aarch64 reverse debugging test is unreliable +Description of problem: +The reverse-debugging test for the aarch64 target is not working reliably, especially if the host system is under load, approx. 1 or 2 out of 10 test runs fail. The log looks like this: + +``` +2025-04-14 10:24:35,042 test L0310 INFO | INIT 1-ReverseDebugging_AArch64.test_aarch64_virt +2025-04-14 10:24:35,043 parameters L0142 DEBUG| PARAMS (key=timeout, path=*, default=10) => 10 +2025-04-14 10:24:35,043 test L0338 DEBUG| Test metadata: +2025-04-14 10:24:35,043 test L0340 DEBUG| filename: /.../tmp/qemu-build/tests/avocado/reverse_debugging.py +2025-04-14 10:24:35,044 test L0346 DEBUG| teststmpdir: /var/tmp/avocado_w5d2bkam +2025-04-14 10:24:35,044 test L0536 INFO | START 1-ReverseDebugging_AArch64.test_aarch64_virt +2025-04-14 10:24:35,044 test L0207 DEBUG| DATA (filename=output.expected) => NOT FOUND (data sources: variant, test, file) +2025-04-14 10:24:35,045 parameters L0142 DEBUG| PARAMS (key=arch, path=*, default=aarch64) => 'aarch64' +2025-04-14 10:24:35,045 parameters L0142 DEBUG| PARAMS (key=cpu, path=*, default=cortex-a53) => 'cortex-a53' +2025-04-14 10:24:35,046 parameters L0142 DEBUG| PARAMS (key=qemu_bin, path=*, default=./qemu-system-aarch64) => './qemu-system-aarch64' +2025-04-14 10:24:35,272 parameters L0142 DEBUG| PARAMS (key=machine, path=*, default=virt) => 'virt' +2025-04-14 10:24:35,290 test L0465 DEBUG| Test workdir initialized at: /var/tmp/.avocado-taskky_yb2qf/test-results/tmp_dir56wqq7g0/1-ReverseDebugging_AArch64.test_aarch64_virt +2025-04-14 10:24:35,290 process L0658 INFO | Running '/.../tmp/qemu-build/qemu-img create -f qcow2 /var/tmp/.avocado-taskky_yb2qf/test-results/tmp_dir56wqq7g0/1-ReverseDebugging_AArch64.test_aarch64_virt/disk.qcow2 128M' +2025-04-14 10:24:35,347 process L0470 DEBUG| [stdout] Formatting '/var/tmp/.avocado-taskky_yb2qf/test-results/tmp_dir56wqq7g0/1-ReverseDebugging_AArch64.test_aarch64_virt/disk.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=134217728 lazy_refcounts=off refcount_bits=16 +2025-04-14 10:24:35,393 process L0739 INFO | Command '/.../tmp/qemu-build/qemu-img create -f qcow2 /var/tmp/.avocado-taskky_yb2qf/test-results/tmp_dir56wqq7g0/1-ReverseDebugging_AArch64.test_aarch64_virt/disk.qcow2 128M' finished with 0 after 0.100170269s +2025-04-14 10:24:35,475 __init__ L0314 DEBUG| QEMUMachine "28fc0d7d-bd0a-44c0-afa8-f24a1800132f" created +2025-04-14 10:24:35,475 __init__ L0315 DEBUG| QEMUMachine "28fc0d7d-bd0a-44c0-afa8-f24a1800132f" temp_dir: /var/tmp/.avocado-taskky_yb2qf/test-results/tmp_dir56wqq7g0/1-ReverseDebugging_AArch64.test_aarch64_virt/qemu-machine-052_8e_k +2025-04-14 10:24:35,475 __init__ L0316 DEBUG| QEMUMachine "28fc0d7d-bd0a-44c0-afa8-f24a1800132f" log_dir: /var/tmp/.avocado-taskky_yb2qf/test-results/1-ReverseDebugging_AArch64.test_aarch64_virt +2025-04-14 10:24:36,195 __init__ L0314 DEBUG| QEMUMachine "3f348d83-7aa3-4381-9919-389bc85ed85b" created +2025-04-14 10:24:36,196 __init__ L0315 DEBUG| QEMUMachine "3f348d83-7aa3-4381-9919-389bc85ed85b" temp_dir: /var/tmp/.avocado-taskky_yb2qf/test-results/tmp_dir56wqq7g0/1-ReverseDebugging_AArch64.test_aarch64_virt/qemu-machine-vxlortdq +2025-04-14 10:24:36,196 __init__ L0316 DEBUG| QEMUMachine "3f348d83-7aa3-4381-9919-389bc85ed85b" log_dir: /var/tmp/.avocado-taskky_yb2qf/test-results/1-ReverseDebugging_AArch64.test_aarch64_virt +2025-04-14 10:24:37,623 stacktrace L0039 ERROR| +2025-04-14 10:24:37,628 stacktrace L0041 ERROR| Reproduced traceback from: /usr/lib/python3.13/site-packages/avocado/core/test.py:793 +2025-04-14 10:24:37,643 stacktrace L0045 ERROR| Traceback (most recent call last): +2025-04-14 10:24:37,643 stacktrace L0045 ERROR| File "/usr/lib/python3.13/site-packages/avocado/core/decorators.py", line 90, in wrapper +2025-04-14 10:24:37,643 stacktrace L0045 ERROR| return function(obj, *args, **kwargs) +2025-04-14 10:24:37,643 stacktrace L0045 ERROR| File "/.../tmp/qemu-build/tests/avocado/reverse_debugging.py", line 239, in test_aarch64_virt +2025-04-14 10:24:37,644 stacktrace L0045 ERROR| self.reverse_debugging( +2025-04-14 10:24:37,644 stacktrace L0045 ERROR| ~~~~~~~~~~~~~~~~~~~~~~^ +2025-04-14 10:24:37,644 stacktrace L0045 ERROR| args=('-kernel', kernel_path)) +2025-04-14 10:24:37,644 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,644 stacktrace L0045 ERROR| File "/.../tmp/qemu-build/tests/avocado/reverse_debugging.py", line 179, in reverse_debugging +2025-04-14 10:24:37,644 stacktrace L0045 ERROR| if self.vm_get_icount(vm) == last_icount - 1: +2025-04-14 10:24:37,644 stacktrace L0045 ERROR| ~~~~~~~~~~~~~~~~~~^^^^ +2025-04-14 10:24:37,644 stacktrace L0045 ERROR| File "/.../tmp/qemu-build/tests/avocado/reverse_debugging.py", line 100, in vm_get_icount +2025-04-14 10:24:37,644 stacktrace L0045 ERROR| return vm.qmp('query-replay')['return']['icount'] +2025-04-14 10:24:37,644 stacktrace L0045 ERROR| ~~~~~~^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,645 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/machine/machine.py", line 711, in qmp +2025-04-14 10:24:37,645 stacktrace L0045 ERROR| ret = self._qmp.cmd_raw(cmd, args=qmp_args) +2025-04-14 10:24:37,645 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 208, in cmd_raw +2025-04-14 10:24:37,645 stacktrace L0045 ERROR| return self.cmd_obj(qmp_cmd) +2025-04-14 10:24:37,645 stacktrace L0045 ERROR| ~~~~~~~~~~~~^^^^^^^^^ +2025-04-14 10:24:37,645 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 186, in cmd_obj +2025-04-14 10:24:37,645 stacktrace L0045 ERROR| self._sync( +2025-04-14 10:24:37,645 stacktrace L0045 ERROR| ~~~~~~~~~~^ +2025-04-14 10:24:37,645 stacktrace L0045 ERROR| # pylint: disable=protected-access +2025-04-14 10:24:37,645 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,646 stacktrace L0045 ERROR| ...<5 lines>... +2025-04-14 10:24:37,646 stacktrace L0045 ERROR| self._timeout +2025-04-14 10:24:37,646 stacktrace L0045 ERROR| ^^^^^^^^^^^^^ +2025-04-14 10:24:37,646 stacktrace L0045 ERROR| ) +2025-04-14 10:24:37,646 stacktrace L0045 ERROR| ^ +2025-04-14 10:24:37,646 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 102, in _sync +2025-04-14 10:24:37,646 stacktrace L0045 ERROR| return self._aloop.run_until_complete( +2025-04-14 10:24:37,647 stacktrace L0045 ERROR| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ +2025-04-14 10:24:37,647 stacktrace L0045 ERROR| asyncio.wait_for(future, timeout=timeout) +2025-04-14 10:24:37,647 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,647 stacktrace L0045 ERROR| ) +2025-04-14 10:24:37,647 stacktrace L0045 ERROR| ^ +2025-04-14 10:24:37,647 stacktrace L0045 ERROR| File "/usr/lib64/python3.13/asyncio/base_events.py", line 725, in run_until_complete +2025-04-14 10:24:37,647 stacktrace L0045 ERROR| return future.result() +2025-04-14 10:24:37,647 stacktrace L0045 ERROR| ~~~~~~~~~~~~~^^ +2025-04-14 10:24:37,647 stacktrace L0045 ERROR| File "/usr/lib64/python3.13/asyncio/tasks.py", line 507, in wait_for +2025-04-14 10:24:37,648 stacktrace L0045 ERROR| return await fut +2025-04-14 10:24:37,648 stacktrace L0045 ERROR| ^^^^^^^^^ +2025-04-14 10:24:37,648 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 547, in _raw +2025-04-14 10:24:37,648 stacktrace L0045 ERROR| return await self._execute(msg, assign_id=assign_id) +2025-04-14 10:24:37,648 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,648 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 496, in _execute +2025-04-14 10:24:37,648 stacktrace L0045 ERROR| return await self._reply(exec_id) +2025-04-14 10:24:37,648 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,648 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 463, in _reply +2025-04-14 10:24:37,648 stacktrace L0045 ERROR| raise result +2025-04-14 10:24:37,648 stacktrace L0045 ERROR| qemu.qmp.qmp_client.ExecInterruptedError: Disconnected +2025-04-14 10:24:37,649 stacktrace L0046 ERROR| +2025-04-14 10:24:37,649 test L0798 DEBUG| Local variables: +2025-04-14 10:24:37,671 test L0801 DEBUG| -> obj <class 'reverse_debugging.ReverseDebugging_AArch64'>: 1-ReverseDebugging_AArch64.test_aarch64_virt +2025-04-14 10:24:37,671 test L0801 DEBUG| -> args <class 'tuple'>: () +2025-04-14 10:24:37,671 test L0801 DEBUG| -> kwargs <class 'dict'>: {} +2025-04-14 10:24:37,671 test L0801 DEBUG| -> condition <class 'str'>: 1 +2025-04-14 10:24:37,671 test L0801 DEBUG| -> function <class 'function'>: <function ReverseDebugging_AArch64.test_aarch64_virt at 0x7fc6d4cc87c0> +2025-04-14 10:24:37,672 test L0801 DEBUG| -> message <class 'str'>: Test is unstable on GitLab +2025-04-14 10:24:37,672 test L0801 DEBUG| -> negate <class 'bool'>: True +2025-04-14 10:24:37,673 stacktrace L0039 ERROR| +2025-04-14 10:24:37,673 stacktrace L0041 ERROR| Reproduced traceback from: /usr/lib/python3.13/site-packages/avocado/core/test.py:819 +2025-04-14 10:24:37,678 stacktrace L0045 ERROR| Traceback (most recent call last): +2025-04-14 10:24:37,679 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/machine/machine.py", line 580, in _soft_shutdown +2025-04-14 10:24:37,679 stacktrace L0045 ERROR| self.qmp('quit') +2025-04-14 10:24:37,679 stacktrace L0045 ERROR| ~~~~~~~~^^^^^^^^ +2025-04-14 10:24:37,679 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/machine/machine.py", line 711, in qmp +2025-04-14 10:24:37,679 stacktrace L0045 ERROR| ret = self._qmp.cmd_raw(cmd, args=qmp_args) +2025-04-14 10:24:37,679 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 208, in cmd_raw +2025-04-14 10:24:37,679 stacktrace L0045 ERROR| return self.cmd_obj(qmp_cmd) +2025-04-14 10:24:37,679 stacktrace L0045 ERROR| ~~~~~~~~~~~~^^^^^^^^^ +2025-04-14 10:24:37,679 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 192, in cmd_obj +2025-04-14 10:24:37,680 stacktrace L0045 ERROR| self._qmp._raw(qmp_cmd, assign_id=False), +2025-04-14 10:24:37,680 stacktrace L0045 ERROR| ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,680 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 155, in _wrapper +2025-04-14 10:24:37,680 stacktrace L0045 ERROR| raise StateError(emsg, proto.runstate, required_state) +2025-04-14 10:24:37,680 stacktrace L0045 ERROR| qemu.qmp.protocol.StateError: QMPClient is disconnecting. Call disconnect() to return to IDLE state. +2025-04-14 10:24:37,680 stacktrace L0045 ERROR| +2025-04-14 10:24:37,680 stacktrace L0045 ERROR| During handling of the above exception, another exception occurred: +2025-04-14 10:24:37,680 stacktrace L0045 ERROR| +2025-04-14 10:24:37,680 stacktrace L0045 ERROR| Traceback (most recent call last): +2025-04-14 10:24:37,680 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/machine/machine.py", line 611, in _do_shutdown +2025-04-14 10:24:37,681 stacktrace L0045 ERROR| self._soft_shutdown(timeout) +2025-04-14 10:24:37,681 stacktrace L0045 ERROR| ~~~~~~~~~~~~~~~~~~~^^^^^^^^^ +2025-04-14 10:24:37,681 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/machine/machine.py", line 583, in _soft_shutdown +2025-04-14 10:24:37,681 stacktrace L0045 ERROR| self._close_qmp_connection() +2025-04-14 10:24:37,681 stacktrace L0045 ERROR| ~~~~~~~~~~~~~~~~~~~~~~~~~~^^ +2025-04-14 10:24:37,681 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/machine/machine.py", line 501, in _close_qmp_connection +2025-04-14 10:24:37,681 stacktrace L0045 ERROR| self._qmp.close() +2025-04-14 10:24:37,681 stacktrace L0045 ERROR| ~~~~~~~~~~~~~~~^^ +2025-04-14 10:24:37,681 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 281, in close +2025-04-14 10:24:37,681 stacktrace L0045 ERROR| self._sync( +2025-04-14 10:24:37,681 stacktrace L0045 ERROR| ~~~~~~~~~~^ +2025-04-14 10:24:37,682 stacktrace L0045 ERROR| self._qmp.disconnect() +2025-04-14 10:24:37,682 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,682 stacktrace L0045 ERROR| ) +2025-04-14 10:24:37,682 stacktrace L0045 ERROR| ^ +2025-04-14 10:24:37,682 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 102, in _sync +2025-04-14 10:24:37,682 stacktrace L0045 ERROR| return self._aloop.run_until_complete( +2025-04-14 10:24:37,682 stacktrace L0045 ERROR| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ +2025-04-14 10:24:37,682 stacktrace L0045 ERROR| asyncio.wait_for(future, timeout=timeout) +2025-04-14 10:24:37,682 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,682 stacktrace L0045 ERROR| ) +2025-04-14 10:24:37,682 stacktrace L0045 ERROR| ^ +2025-04-14 10:24:37,683 stacktrace L0045 ERROR| File "/usr/lib64/python3.13/asyncio/base_events.py", line 725, in run_until_complete +2025-04-14 10:24:37,683 stacktrace L0045 ERROR| return future.result() +2025-04-14 10:24:37,683 stacktrace L0045 ERROR| ~~~~~~~~~~~~~^^ +2025-04-14 10:24:37,683 stacktrace L0045 ERROR| File "/usr/lib64/python3.13/asyncio/tasks.py", line 507, in wait_for +2025-04-14 10:24:37,683 stacktrace L0045 ERROR| return await fut +2025-04-14 10:24:37,683 stacktrace L0045 ERROR| ^^^^^^^^^ +2025-04-14 10:24:37,683 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 399, in disconnect +2025-04-14 10:24:37,683 stacktrace L0045 ERROR| await self._wait_disconnect() +2025-04-14 10:24:37,683 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 719, in _wait_disconnect +2025-04-14 10:24:37,683 stacktrace L0045 ERROR| await all_defined_tasks # Raise Exceptions from the bottom half. +2025-04-14 10:24:37,684 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,684 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 870, in _bh_loop_forever +2025-04-14 10:24:37,684 stacktrace L0045 ERROR| await async_fn() +2025-04-14 10:24:37,684 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 908, in _bh_recv_message +2025-04-14 10:24:37,684 stacktrace L0045 ERROR| msg = await self._recv() +2025-04-14 10:24:37,684 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,684 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 1009, in _recv +2025-04-14 10:24:37,684 stacktrace L0045 ERROR| message = await self._do_recv() +2025-04-14 10:24:37,684 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,684 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 402, in _do_recv +2025-04-14 10:24:37,684 stacktrace L0045 ERROR| msg_bytes = await self._readline() +2025-04-14 10:24:37,685 stacktrace L0045 ERROR| ^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,685 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 977, in _readline +2025-04-14 10:24:37,685 stacktrace L0045 ERROR| raise EOFError +2025-04-14 10:24:37,685 stacktrace L0045 ERROR| EOFError +2025-04-14 10:24:37,685 stacktrace L0045 ERROR| +2025-04-14 10:24:37,685 stacktrace L0045 ERROR| The above exception was the direct cause of the following exception: +2025-04-14 10:24:37,685 stacktrace L0045 ERROR| +2025-04-14 10:24:37,685 stacktrace L0045 ERROR| Traceback (most recent call last): +2025-04-14 10:24:37,685 stacktrace L0045 ERROR| File "/.../tmp/qemu-build/tests/avocado/avocado_qemu/__init__.py", line 372, in tearDown +2025-04-14 10:24:37,685 stacktrace L0045 ERROR| vm.shutdown() +2025-04-14 10:24:37,685 stacktrace L0045 ERROR| ~~~~~~~~~~~^^ +2025-04-14 10:24:37,686 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/machine/machine.py", line 648, in shutdown +2025-04-14 10:24:37,686 stacktrace L0045 ERROR| self._do_shutdown(timeout) +2025-04-14 10:24:37,686 stacktrace L0045 ERROR| ~~~~~~~~~~~~~~~~~^^^^^^^^^ +2025-04-14 10:24:37,686 stacktrace L0045 ERROR| File "/.../devel/qemu/python/qemu/machine/machine.py", line 618, in _do_shutdown +2025-04-14 10:24:37,686 stacktrace L0045 ERROR| raise AbnormalShutdown("Could not perform graceful shutdown") \ +2025-04-14 10:24:37,686 stacktrace L0045 ERROR| from exc +2025-04-14 10:24:37,686 stacktrace L0045 ERROR| qemu.machine.machine.AbnormalShutdown: Could not perform graceful shutdown +2025-04-14 10:24:37,686 stacktrace L0046 ERROR| +2025-04-14 10:24:37,694 test L0941 ERROR| Traceback (most recent call last): +2025-04-14 10:24:37,694 test L0941 ERROR| File "/usr/lib/python3.13/site-packages/avocado/core/test.py", line 881, in _run_avocado + raise test_exception +2025-04-14 10:24:37,694 test L0941 ERROR| File "/usr/lib/python3.13/site-packages/avocado/core/test.py", line 788, in _run_avocado + testMethod() + ~~~~~~~~~~^^ +2025-04-14 10:24:37,695 test L0941 ERROR| File "/usr/lib/python3.13/site-packages/avocado/core/decorators.py", line 90, in wrapper + return function(obj, *args, **kwargs) +2025-04-14 10:24:37,695 test L0941 ERROR| File "/.../tmp/qemu-build/tests/avocado/reverse_debugging.py", line 239, in test_aarch64_virt + self.reverse_debugging( + ~~~~~~~~~~~~~~~~~~~~~~^ + args=('-kernel', kernel_path)) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,695 test L0941 ERROR| File "/.../tmp/qemu-build/tests/avocado/reverse_debugging.py", line 179, in reverse_debugging + if self.vm_get_icount(vm) == last_icount - 1: + ~~~~~~~~~~~~~~~~~~^^^^ +2025-04-14 10:24:37,695 test L0941 ERROR| File "/.../tmp/qemu-build/tests/avocado/reverse_debugging.py", line 100, in vm_get_icount + return vm.qmp('query-replay')['return']['icount'] + ~~~~~~^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,695 test L0941 ERROR| File "/.../devel/qemu/python/qemu/machine/machine.py", line 711, in qmp + ret = self._qmp.cmd_raw(cmd, args=qmp_args) +2025-04-14 10:24:37,695 test L0941 ERROR| File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 208, in cmd_raw + return self.cmd_obj(qmp_cmd) + ~~~~~~~~~~~~^^^^^^^^^ +2025-04-14 10:24:37,695 test L0941 ERROR| File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 186, in cmd_obj + self._sync( + ~~~~~~~~~~^ + # pylint: disable=protected-access + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ...<5 lines>... + self._timeout + ^^^^^^^^^^^^^ + ) + ^ +2025-04-14 10:24:37,695 test L0941 ERROR| File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 102, in _sync + return self._aloop.run_until_complete( + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ + asyncio.wait_for(future, timeout=timeout) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ) + ^ +2025-04-14 10:24:37,695 test L0941 ERROR| File "/usr/lib64/python3.13/asyncio/base_events.py", line 725, in run_until_complete + return future.result() + ~~~~~~~~~~~~~^^ +2025-04-14 10:24:37,695 test L0941 ERROR| File "/usr/lib64/python3.13/asyncio/tasks.py", line 507, in wait_for + return await fut + ^^^^^^^^^ +2025-04-14 10:24:37,696 test L0941 ERROR| File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 547, in _raw + return await self._execute(msg, assign_id=assign_id) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,696 test L0941 ERROR| File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 496, in _execute + return await self._reply(exec_id) + ^^^^^^^^^^^^^^^^^^^^^^^^^^ +2025-04-14 10:24:37,696 test L0941 ERROR| File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 463, in _reply + raise result +2025-04-14 10:24:37,696 test L0941 ERROR| qemu.qmp.qmp_client.ExecInterruptedError: Disconnected +2025-04-14 10:24:37,696 test L0956 ERROR| ERROR 1-ReverseDebugging_AArch64.test_aarch64_virt -> ExecInterruptedError: Disconnected +2025-04-14 10:24:37,696 test L0948 INFO | +``` +Steps to reproduce: +1. ``make check-venv`` +2. Run something in the background that keeps all CPUs busy +3. ``for ((x=0;x<20;x++)); do QEMU_TEST_FLAKY_TESTS=1 pyvenv/bin/avocado run tests/avocado/reverse_debugging.py:ReverseDebugging_AArch64.test_aarch64_virt ; done`` +Additional information: +The problem can be reproduced with the test converted to the functional framework, too (that's where I noticed it first). In that case the stack trace looked like this: + +``` +$ QEMU_TEST_ALLOW_SLOW=1 QEMU_TEST_ALLOW_UNTRUSTED_CODE=1 QEMU_TEST_FLAKY_TESTS=1 QEMU_TEST_ALLOW_LARGE_STORAGE=1 ~/devel/qemu/tests/functional/test_aarch64_reverse_debug.py +TAP version 13 +Traceback (most recent call last): + File "/.../devel/qemu/tests/functional/test_aarch64_reverse_debug.py", line 33, in test_aarch64_virt + self.reverse_debugging(args=('-kernel', kernel_path)) + ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/.../devel/qemu/tests/functional/reverse_debugging.py", line 147, in reverse_debugging + pc = self.get_pc(g) + File "/.../devel/qemu/tests/functional/reverse_debugging.py", line 82, in get_pc + return self.get_reg(g, self.REG_PC) + ~~~~~~~~~~~~^^^^^^^^^^^^^^^^ + File "/.../devel/qemu/tests/functional/reverse_debugging.py", line 77, in get_reg + return self.get_reg_le(g, reg) + ~~~~~~~~~~~~~~~^^^^^^^^ + File "/.../devel/qemu/tests/functional/reverse_debugging.py", line 63, in get_reg_le + res = g.cmd(b'p%x' % reg) + File "/usr/lib/python3.13/site-packages/avocado/utils/gdb.py", line 783, in cmd + response_payload = self.decode(result) + File "/usr/lib/python3.13/site-packages/avocado/utils/gdb.py", line 738, in decode + raise InvalidPacketError +avocado.utils.gdb.InvalidPacketError + +not ok 1 test_aarch64_reverse_debug.ReverseDebugging_AArch64.test_aarch64_virt +Traceback (most recent call last): + File "/.../devel/qemu/python/qemu/machine/machine.py", line 580, in _soft_shutdown + self.qmp('quit') + ~~~~~~~~^^^^^^^^ + File "/.../devel/qemu/python/qemu/machine/machine.py", line 711, in qmp + ret = self._qmp.cmd_raw(cmd, args=qmp_args) + File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 208, in cmd_raw + return self.cmd_obj(qmp_cmd) + ~~~~~~~~~~~~^^^^^^^^^ + File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 186, in cmd_obj + self._sync( + ~~~~~~~~~~^ + # pylint: disable=protected-access + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ...<5 lines>... + self._timeout + ^^^^^^^^^^^^^ + ) + ^ + File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 102, in _sync + return self._aloop.run_until_complete( + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ + asyncio.wait_for(future, timeout=timeout) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ) + ^ + File "/usr/lib64/python3.13/asyncio/base_events.py", line 725, in run_until_complete + return future.result() + ~~~~~~~~~~~~~^^ + File "/usr/lib64/python3.13/asyncio/tasks.py", line 507, in wait_for + return await fut + ^^^^^^^^^ + File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 547, in _raw + return await self._execute(msg, assign_id=assign_id) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 496, in _execute + return await self._reply(exec_id) + ^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/.../devel/qemu/python/qemu/qmp/qmp_client.py", line 463, in _reply + raise result +qemu.qmp.qmp_client.ExecInterruptedError: Disconnected + +During handling of the above exception, another exception occurred: + +Traceback (most recent call last): + File "/.../devel/qemu/python/qemu/machine/machine.py", line 611, in _do_shutdown + self._soft_shutdown(timeout) + ~~~~~~~~~~~~~~~~~~~^^^^^^^^^ + File "/.../devel/qemu/python/qemu/machine/machine.py", line 583, in _soft_shutdown + self._close_qmp_connection() + ~~~~~~~~~~~~~~~~~~~~~~~~~~^^ + File "/.../devel/qemu/python/qemu/machine/machine.py", line 501, in _close_qmp_connection + self._qmp.close() + ~~~~~~~~~~~~~~~^^ + File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 281, in close + self._sync( + ~~~~~~~~~~^ + self._qmp.disconnect() + ^^^^^^^^^^^^^^^^^^^^^^ + ) + ^ + File "/.../devel/qemu/python/qemu/qmp/legacy.py", line 102, in _sync + return self._aloop.run_until_complete( + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ + asyncio.wait_for(future, timeout=timeout) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + ) + ^ + File "/usr/lib64/python3.13/asyncio/base_events.py", line 725, in run_until_complete + return future.result() + ~~~~~~~~~~~~~^^ + File "/usr/lib64/python3.13/asyncio/tasks.py", line 507, in wait_for + return await fut + ^^^^^^^^^ + File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 399, in disconnect + await self._wait_disconnect() + File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 719, in _wait_disconnect + await all_defined_tasks # Raise Exceptions from the bottom half. + ^^^^^^^^^^^^^^^^^^^^^^^ + File "/.../devel/qemu/python/qemu/qmp/protocol.py", line 834, in _bh_close_stream + await wait_closed(self._writer) + File "/.../devel/qemu/python/qemu/qmp/util.py", line 130, in wait_closed + await writer.wait_closed() + File "/usr/lib64/python3.13/asyncio/streams.py", line 358, in wait_closed + await self._protocol._get_close_waiter(self) + File "/usr/lib64/python3.13/asyncio/selector_events.py", line 1067, in write + n = self._sock.send(data) +BrokenPipeError: [Errno 32] Broken pipe + +The above exception was the direct cause of the following exception: + +Traceback (most recent call last): + File "/.../devel/qemu/tests/functional/qemu_test/testcase.py", line 398, in tearDown + vm.shutdown() + ~~~~~~~~~~~^^ + File "/.../devel/qemu/python/qemu/machine/machine.py", line 648, in shutdown + self._do_shutdown(timeout) + ~~~~~~~~~~~~~~~~~^^^^^^^^^ + File "/.../devel/qemu/python/qemu/machine/machine.py", line 618, in _do_shutdown + raise AbnormalShutdown("Could not perform graceful shutdown") \ + from exc +qemu.machine.machine.AbnormalShutdown: Could not perform graceful shutdown + +not ok 1 test_aarch64_reverse_debug.ReverseDebugging_AArch64.test_aarch64_virt +1..1 +``` diff --git a/results/classifier/gemma3:12b/debug/2922 b/results/classifier/gemma3:12b/debug/2922 new file mode 100644 index 000000000..a3468a9b5 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2922 @@ -0,0 +1,8 @@ + +x86 reverse-debugging test is unreliable +Description of problem: +The reverse-debugging test for the x86 target is not working reliably. If the host system is under load, the test simply hangs and finally times out. +Steps to reproduce: +1. ``make check-venv`` +2. Run something in the background that keeps all CPUs busy +3. ``for ((x=0;x<10;x++)); do QEMU_TEST_FLAKY_TESTS=1 pyvenv/bin/avocado run tests/avocado/reverse_debugging.py:ReverseDebugging_X86_64.test_x86_64_pc ; done`` diff --git a/results/classifier/gemma3:12b/debug/2924 b/results/classifier/gemma3:12b/debug/2924 new file mode 100644 index 000000000..fef6a358e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2924 @@ -0,0 +1,16 @@ + +qemu-user not responding to Ctrl-C from gdb +Description of problem: +When attached to qemu-x84_64's gdbserver via gdb, it is not possible to interrupt the binary being emulated. Usually, Ctrl-C will interrupt a running binary from gdb and I believe (though have not tested) it works in qemu-system. + +First Ctrl-C will do nothing and second will prompt to stop debugging. +``` +(gdb) c +Continuing. +^C^CThe target is not responding to interrupt requests. +Stop debugging it? (y or n) +``` +Steps to reproduce: +1. Run `./qemu-x86_64 -g 1234 ~/Downloads/base64-x64_64-static` or any static binary that will pause/hang +2. Connect from gdb `(gdb) target remote :1234` +3. Ctrl-C in gdb diff --git a/results/classifier/gemma3:12b/debug/2927 b/results/classifier/gemma3:12b/debug/2927 new file mode 100644 index 000000000..acaf4acde --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2927 @@ -0,0 +1,172 @@ + +Getting bare metal code running on tricore +Description of problem: +My code is stuck in +Steps to reproduce: +1. Open Infineon Aurix Development Studio (on Windows) +2. Compile project (two examples that I've tested) +a) New -> Project -> Board -> KIT_AURIX_TC277_TFT_DC-Step -> Build +b) the example from here: https://github.com/Infineon/AURIX_code_examples/tree/master/code_examples/Blinky_LED_1_KIT_TC277_TFT +3. Copy the elf and run qemu on the debian system +Additional information: +When running a blank binary on QEMU with the TriCore TC27x target, the CPU starts executing at address 0x80000020 and enters an infinite loop. +The code seems to be stuck and waiting for some hardware signal. The binary (sample.elf) from this issue qemu-project/qemu#1363 works. + +I know it's probably a rookie problem, but what am I missing? How can I get an example from Infineon running? Or any other example? + +Please let me know if you need additional information! + +```:~/qemu$ ./build/qemu-system-tricore -M KIT_AURIX_TC277_TRB -cpu tc27x -nographic -kernel ../qemu-examples/aurix_tricore_example_bins/Blank_project_TC277.elf -d in_asm +QEMU 9.2.50 monitor - type 'help' for more information +(qemu) ---------------- +IN: _START +0x80000020: +OBJD-T: 91000028d9220681dc02 + +---------------- +IN: _Core0_start +0x80001206: +OBJD-T: 9130002f192200469120003737026e21d92200468ff2838180321b026029602a +OBJD-T: 0d0080043b009820cd42e00f + +---------------- +IN: _Core0_start +0x8000120a: +OBJD-T: 19220046 + +---------------- +IN: _Core0_start +0x8000120e: +OBJD-T: 9120003737026e21d92200468ff2838180321b026029602a0d0080043b009820 +OBJD-T: cd42e00f + +---------------- +IN: _Core0_start +0x80001232: +OBJD-T: 4d00e02fb7021420cd02e00f8212cd4220094dc0e12f8f720021012203260122 +OBJD-T: 02265422542337026e218ff283216f134381 + +---------------- +IN: _Core0_start +0x80001254: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x80001256: +OBJD-T: 542337026e218ff283216f134381 + +---------------- +IN: _Core0_start +0x80001256: +OBJD-T: 5423 + +---------------- +IN: _Core0_start +0x80001258: +OBJD-T: 37026e218ff283216f134381 + +---------------- +IN: _Core0_start +0x80001264: +OBJD-T: 8f2200305422b7021020a6328f224021742254226f02ffff + +---------------- +IN: _Core0_start +0x80001268: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x8000126a: +OBJD-T: b7021020a6328f224021742254226f02ffff + +---------------- +IN: _Core0_start +0x80001274: +OBJD-T: 7422 + +---------------- +IN: _Core0_start +0x80001276: +OBJD-T: 54226f02ffff + +---------------- +IN: _Core0_start +0x80001276: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x80001278: +OBJD-T: 6f02ffff + +---------------- +IN: _Core0_start +0x8000127c: +OBJD-T: 8202cdc2200954226f120900 + +---------------- +IN: _Core0_start +0x80001282: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x80001284: +OBJD-T: 6f120900 + +---------------- +IN: _Core0_start +0x80001296: +OBJD-T: 5422b7021020a6328f324021742254226f02ff7f + +---------------- +IN: _Core0_start +0x80001296: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x80001298: +OBJD-T: b7021020a6328f324021742254226f02ff7f + +---------------- +IN: _Core0_start +0x800012a2: +OBJD-T: 7422 + +---------------- +IN: _Core0_start +0x800012a4: +OBJD-T: 54226f02ff7f + +---------------- +IN: _Core0_start +0x800012a4: +OBJD-T: 5422 + +---------------- +IN: _Core0_start +0x800012a6: +OBJD-T: 6f02ff7f + + +(qemu) q +``` + +When I run it with the `-d in_asm,cpu,exec` flag it logs this infinitely often: +``` +Trace 0: 0x7fb5205e9940 [00000000/00000000800012a4/00000002/ff011001] _Core0_start +PC: 800012a4 PSW: 00000980 ICR: 00000000 +PCXI: 00000000 FCX: 00000000 LCX: 00000000 +GPR A00: 00000000 00000000 f0036100 70020000 +GPR A04: 00000000 00000000 00000000 00000000 +GPR A08: 00000000 00000000 70019600 00000000 +GPR A12: 00000000 00000000 00000000 00000000 +GPR D00: 00000000 00000000 00000000 000000fc +GPR D04: 00000000 00000000 00000000 00000000 +GPR D08: 0000003f 00000000 00000000 00000000 +GPR D12: 00000000 00000000 00000000 00000000 +cpu_io_recompile: rewound execution of TB to 00000000800012a4 +``` diff --git a/results/classifier/gemma3:12b/debug/2942 b/results/classifier/gemma3:12b/debug/2942 new file mode 100644 index 000000000..df74e9216 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2942 @@ -0,0 +1,66 @@ + +arm: TCG debug assertion failure when handling an ISB or SB insn inside an IT block +Description of problem: +ARM thumb `IT` instruction triggers TCG debug asserts. + +``` +$ ./qemu-system-arm --version +QEMU emulator version 10.0.0 (v10.0.0) + +$ ./qemu-system-arm -M stm32vldiscovery -nographic -device loader,file=raw-it-bug.hex -d in_asm,exec +[...] +Trace 0: 0x72a584000800 [00800400/0000000000000164/00000110/ff020000] +---------------- +IN: +0x00000108: f000 f80a bl #0x120 + +Trace 0: 0x72a584000940 [00800400/0000000000000108/00000110/ff020000] +qemu-system-arm: ../tcg/tcg-op.c:3343: void tcg_gen_goto_tb(unsigned int): Assertion `(tcg_ctx->goto_tb_issue_mask & (1 << idx)) == 0' failed. +``` + +Expected behavior: +``` +$ qemu-system-arm -M stm32vldiscovery -device loader,file=raw-hardfault.hex -d in_asm,exec,int +[...] +Trace 0: 0x7df6dc000800 [00800400/0000000000000164/00000110/ff020000] +---------------- +IN: +0x00000108: f000 f80a bl #0x120 + +Trace 0: 0x7df6dc000940 [00800400/0000000000000108/00000110/ff020000] +---------------- +IN: +0x00000120: 2302 movs r3, #2 +0x00000122: bf00 nop +0x00000124: f04f 25e0 mov.w r5, #-0x1fff2000 +0x00000128: f8d5 1d10 ldr.w r1, [r5, #0xd10] +0x0000012c: f041 0014 orr r0, r1, #0x14 +0x00000130: f8c5 0d10 str.w r0, [r5, #0xd10] +0x00000134: f8d5 0200 ldr.w r0, [r5, #0x200] +0x00000138: f8d5 6100 ldr.w r6, [r5, #0x100] +0x0000013c: 4206 tst r6, r0 +0x0000013e: bf02 ittt eq +0x00000140: f3bf 8f4f dsbeq sy +0x00000144: bf20 wfeeq + +Linking TBs 0x7df6dc000940 index 0 -> 0x7df6dc000a80 +Trace 0: 0x7df6dc000a80 [00800400/0000000000000120/00000110/ff020000] +[...] +Trace 0: 0x7df6dc001fc0 [00800400/0000000000000170/00000110/ff020000] +Taking exception 3 [Prefetch Abort] on CPU 0 +...at fault address 0xdeadbeee +...with CFSR.IACCVIOL +...BusFault with BFSR.STKERR +...taking pending nonsecure exception 3 +...loading from element 3 of non-secure vector table at 0xc +...loaded new PC 0x111 +---------------- +IN: +0x00000110: e7fe b #0x110 +``` +Steps to reproduce: +1. Build QEMU with `CONFIG_DEBUG_TCG` enabled, e.g. with `./configure --enable-debug`. +1. Run Cortex-M firmware with `IT` instruction. (minimal example attached) +Additional information: +- Minimal Reproducer: [raw-it-bug.hex](/uploads/3ae30ab78f49bbc933e48c51f6bf2a2b/raw-it-bug.hex) +- Reproduced on `main`, `v10.0.0` and `v9.1.0`. diff --git a/results/classifier/gemma3:12b/debug/2963 b/results/classifier/gemma3:12b/debug/2963 new file mode 100644 index 000000000..b62bbb500 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2963 @@ -0,0 +1,25 @@ + +QEMU crash with `qemu_mutex_unlock_impl: Operation not permitted` during block device operations +Description of problem: +We got a crash when I use a blockdev-add command while a blockdev-backup operation was nearly complete. The crash does not reproduce consistently. + +This message was printed in the QEMU debug log. +`qemu: qemu_mutex_unlock_impl: Operation not permitted` + +We also collected a coredump at the time of the crash. but, when analyzing the coredump using gdb, the call stack only shows ?? for all frames, making it difficult to diagnose the root cause. + +so I have two main questions: + +1. Under what circumstances does `qemu_mutex_unlock_impl: Operation not permitted` occur? +Is there any known cause or workaround for this kind of crash? + +2. What should be done to ensure that the call stack in a coredump is visible? +Are there specific build flags or debug symbol requirements we should be aware of? +We built QEMU with --enable-debug, but the call stack still shows only ?? in gdb when analyzing the core dump. +Steps to reproduce: +1. Start a VM with block devices configured. +2. Begin a blockdev-backup operation. +3. Near the completion of the blockdev-backup, issue a blockdev-add command for another device. +4. Observe a crash. (The crash does not reproduce consistently) +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/2964 b/results/classifier/gemma3:12b/debug/2964 new file mode 100644 index 000000000..f7a9edaca --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2964 @@ -0,0 +1,10 @@ + +How to get the icount value after qemu terminal exit +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: +/label ~"kind::Bug" diff --git a/results/classifier/gemma3:12b/debug/2986 b/results/classifier/gemma3:12b/debug/2986 new file mode 100644 index 000000000..84caa4543 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/2986 @@ -0,0 +1,2 @@ + +ARM register DBGDTR_EL0 incorrectly causes undefined exception diff --git a/results/classifier/gemma3:12b/debug/329 b/results/classifier/gemma3:12b/debug/329 new file mode 100644 index 000000000..b4c56fd6e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/329 @@ -0,0 +1,2 @@ + +qemu 6.0.0 fails to build with clang-11 and --enable-debug diff --git a/results/classifier/gemma3:12b/debug/384 b/results/classifier/gemma3:12b/debug/384 new file mode 100644 index 000000000..6337db118 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/384 @@ -0,0 +1,2 @@ + +qemu-monitor-event command gets stuck randomly diff --git a/results/classifier/gemma3:12b/debug/415 b/results/classifier/gemma3:12b/debug/415 new file mode 100644 index 000000000..956e46ba3 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/415 @@ -0,0 +1,2 @@ + +Error handling: Use TFR() macro where applicable diff --git a/results/classifier/gemma3:12b/debug/454 b/results/classifier/gemma3:12b/debug/454 new file mode 100644 index 000000000..4eeb6bcd3 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/454 @@ -0,0 +1,4 @@ + +edk2-aarch64-code.fd prints a lot of debug output +Additional information: +Currently running a QEMU version built from source with the last commit to pc-bios being 7a3d37a3f2335e18539e821d0c72abe0b22480bd (and I don't see any changes to edk2-aarch64-code since) diff --git a/results/classifier/gemma3:12b/debug/458 b/results/classifier/gemma3:12b/debug/458 new file mode 100644 index 000000000..154e322f8 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/458 @@ -0,0 +1,2 @@ + +Xfer:features:read truncating xml sent to gdb frontends diff --git a/results/classifier/gemma3:12b/debug/489 b/results/classifier/gemma3:12b/debug/489 new file mode 100644 index 000000000..301d8b959 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/489 @@ -0,0 +1,38 @@ + +Assertion raised when hitting gdb break point in qemu-system-avr +Description of problem: +An assertion is triggered when inserting a break point via gdb and continuing from gdb until hitting the break point: +``` +./qemu-system-avr -nographic -machine uno -s -S -bios simpletest.bin +Starting up... +qemu-system-avr: ../accel/tcg/translate-all.c:1476: tb_gen_code: Assertion `tb->size != 0' failed. +Aborted (core dumped) +``` +The matching gdb session: +``` +~/gdb/gdb-10.1-OK/gdb/avr-gdb +GNU gdb (GDB) 10.1 +[snipped copyright notice ] +(gdb) tar rem :1234 +Remote debugging using :1234 +warning: Target-supplied registers are not supported by the current architecture +warning: No executable has been specified and target does not support +determining executable automatically. Try using the "file" command. +0x00000000 in ?? () +(gdb) b *0xb2 +Breakpoint 1 at 0xb2 +(gdb) c +Continuing. +Remote connection closed +(gdb) +``` +Steps to reproduce: +1. Start qemu with command line given in description above +2. Connect to qemu session using avr-gdb, also given in description. +3. From avr-gdb, place a break point somewhere in code, then continue +4. When qemu reaches break point, an assertion is raised +Additional information: +1. When running without a break point there is no assertion +2. Problem appears to be triggered only when inserted break point is hit. +3. Stepping in gdb works +4. This problem isn't evident in qemu 6.0.0 diff --git a/results/classifier/gemma3:12b/debug/505 b/results/classifier/gemma3:12b/debug/505 new file mode 100644 index 000000000..c6e52f34d --- /dev/null +++ b/results/classifier/gemma3:12b/debug/505 @@ -0,0 +1,13 @@ + +QEMU crashes when reaching a hardware watchpoint +Description of problem: +When using hardware watchpoints, qemu crashes when it hits the watch point. +See https://github.com/zephyrproject-rtos/zephyr/issues/28613 for the same problem +Steps to reproduce: +1. Download https://download.qemu.org/qemu-6.1.0-rc0.tar.xz +2. Download debian-live-10.10.0-i386-standard.iso from https://cdimage.debian.org/debian-cd/current-live/i386/iso-hybrid/ +3. Build qemu with /configure --target-list=i386-softmmu +4. Run build/qemu-system-i386 -boot d -cdrom debian-live-10.10.0-i386-standard.iso -m 512 -icount auto -gdb tcp:localhost:1234 -S -display none +5. Run gdb and inside gdb run "target remote localhost:1234" +6. In gdb, run "watch *0x0000fff0" and "cont" +7. qemu will crash with ```qemu: fatal: Raised interrupt while not in I/O function``` diff --git a/results/classifier/gemma3:12b/debug/507 b/results/classifier/gemma3:12b/debug/507 new file mode 100644 index 000000000..38bedbea9 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/507 @@ -0,0 +1,57 @@ + +rx / gdbsim-r5f562n7 / serial errors +Description of problem: +Test hangs (about once every two executions) because the console emits an error and expected content is not found. Console content on a failed test execution: + +``` +15:49:05 DEBUG| Linux version 4.19.0+ (yo-satoh@yo-satoh-debian) (gcc version 9.0.0 20181105 (experimental) (GCC)) #137 Wed Feb 20 23:20:02 JST 2019 +15:49:05 DEBUG| Built 1 zonelists, mobility grouping on. Total pages: 8128 +15:49:05 DEBUG| Kernel command line: +15:49:05 DEBUG| Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) +15:49:05 DEBUG| Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) +15:49:05 DEBUG| Memory: 14648K/32768K available (871K kernel code, 95K rwdata, 140K rodata, 96K init, 175K bss, 18120K reserved, 0K cma-reserved) +15:49:05 DEBUG| NR_IRQS: 256 +15:49:05 DEBUG| rx-cmt: used for periodic clock events +15:49:05 DEBUG| clocksource: rx-tpu: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1274173631191 ns +15:49:05 DEBUG| 96.00 BogoMIPS (lpj=480000) +15:49:05 DEBUG| pid_max: default: 4096 minimum: 301 +15:49:05 DEBUG| Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) +15:49:05 DEBUG| Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) +15:49:05 DEBUG| clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns +15:49:05 DEBUG| clocksource: Switched to clocksource rx-tpu +15:49:05 DEBUG| workingset: timestamp_bits=30 max_order=12 bucket_order=0 +15:49:05 DEBUG| SuperH (H)SCI(F) driver initialized +15:49:05 DEBUG| 88240.serial: ttySC0 at MMIO 0x88240 (irq = 215, base_baud = 0) is a sci +15:49:05 DEBUG| console [ttySC0] enabled +15:49:05 DEBUG| 88248.serial: ttySC1 at MMIO 0x88248 (irq = 219, base_baud = 0) is a sci +15:49:05 DEBUG| random: get_random_bytes called from 0x01002e48 with crng_init=0 +15:49:05 DEBUG| Freeing unused kernel memory: 96K +15:49:05 DEBUG| This architecture does not have kernel memory protection. +15:49:05 DEBUG| Run /sbin/init as init process +15:49:05 DEBUG| Run /etc/init as init process +15:49:05 DEBUG| Run /bin/init as init process +15:49:05 DEBUG| Run /bin/sh as init process +15:49:05 DEBUG| Sash command shell (version 1.1.1) +15:49:05 DEBUG| />sh-sci 88240.serial: overrun error +15:49:05 DEBUG| sh-sci 88240.serial: frame error +15:49:05 DEBUG| sh-sci 88240.serial: parity error +15:49:09 DEBUG| random: fast init done +``` + +Instead of the last 4 lines seen here, a successful test contains: + +``` +20:59:53 DEBUG| Sash command shell (version 1.1.1) +20:59:53 DEBUG| /> printenv +20:59:53 DEBUG| HOME=/ +20:59:53 DEBUG| TERM=linux +20:59:53 DEBUG| >>> {'execute': 'quit'} +20:59:53 DEBUG| <<< {'return': {}} +``` + +It was also observed that the test is much more prone to fail when it runs restricted to a single CPU (with taskset). It's not clear to me if this is a Kernel or QEMU issue. +Steps to reproduce: +1. ./configure --target-list=rx-softmmu +2. meson compile +3. make check-venv +4. ./tests/venv/bin/avocado run tests/acceptance/machine_rx_gdbsim.py:RxGdbSimMachine.test_linux_sash diff --git a/results/classifier/gemma3:12b/debug/524 b/results/classifier/gemma3:12b/debug/524 new file mode 100644 index 000000000..c29dceed6 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/524 @@ -0,0 +1,2 @@ + +Giving -smp option a negative argument makes QEMU dump core diff --git a/results/classifier/gemma3:12b/debug/562107 b/results/classifier/gemma3:12b/debug/562107 new file mode 100644 index 000000000..f482ffd1b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/562107 @@ -0,0 +1,13 @@ + +QEmu GDB stub uses IPv6 instead of v4 (or both) + +This bug has been reported by several people already. + +See http://migeel.sk/blog/2009/04/21/gdb-and-qemu-on-windows/ +and http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=5579&p=16248&hilit=gdb+ipv6#p16248 + + +Seems like a very easy fix. + +Regards, +Matthijs ter Woord \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/581353 b/results/classifier/gemma3:12b/debug/581353 new file mode 100644 index 000000000..3b37dbd55 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/581353 @@ -0,0 +1,6 @@ + +qemu doesn't stop execution upon hitting a breakpoint + +Using Qemu 0.12.3 and gdb 7.1 on Ubuntu Lucid. + +I'm trying to debug some bootloader code. Using qemu -s -S to run the bootloader and gdb to connect to qemu, I set the breakpoint at 0x7c00. Then I type continue in gdb. The breakpoint is hit and gdb shows debug information. However qemu apparently continues to execute the code of the bootloader as the text is printed on the screen etc. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/596 b/results/classifier/gemma3:12b/debug/596 new file mode 100644 index 000000000..9bf19c14c --- /dev/null +++ b/results/classifier/gemma3:12b/debug/596 @@ -0,0 +1,2 @@ + +"./ylwrap: -d: not found" error in tricore-debian-cross-container job diff --git a/results/classifier/gemma3:12b/debug/597362 b/results/classifier/gemma3:12b/debug/597362 new file mode 100644 index 000000000..28677cbf3 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/597362 @@ -0,0 +1,71 @@ + +qemu-system-sparc singlestep not work in gdbstub + +Debugging with gdb-stub does not work with qemu-system-sparc target + +Qemu compiled from current git tree. + +execution string: qemu-system-sparc.exe -s -S -m 256 -L Bios -hda +sparc.img -boot c +connect with telnet localhost 1234 +enter '$s#73' (without quotes, this is single step command to gdb stub) +gdb stub reply '+' (without quotes, as it accept command) +After this qemu continuously execute instructions in single step mode +and does not exit to gdb stub after each executed instruction with +interrupt signal +("T%02xthread:%02x;" /gdb_vm_state_change in gdbstub.c/ ); + +If we look at target-sparc/translate.c, we can see that +gen_helper_debug() is not called in single step mode: + +======================== + if ((pc & TARGET_PAGE_MASK) == (tb->pc & TARGET_PAGE_MASK) && + (npc & TARGET_PAGE_MASK) == (tb->pc & TARGET_PAGE_MASK) && + !s->singlestep) { + /* jump to same page: we can use a direct jump */ + tcg_gen_goto_tb(tb_num); + tcg_gen_movi_tl(cpu_pc, pc); + tcg_gen_movi_tl(cpu_npc, npc); + tcg_gen_exit_tb((long)tb + tb_num); + } else { + /* jump to another page: currently not optimized */ + tcg_gen_movi_tl(cpu_pc, pc); + tcg_gen_movi_tl(cpu_npc, npc); + tcg_gen_exit_tb(0); + } +========================= + +======================== + /* if single step mode, we generate only one instruction and + generate an exception */ + if (dc->singlestep) { + break; + } +======================== + +If we look similar code at target-sh4/translate.c we can see that is +called in this cases: + +======================== + if ((tb->pc & TARGET_PAGE_MASK) == (dest & TARGET_PAGE_MASK) && + !ctx->singlestep_enabled) { + /* Use a direct jump if in same page and singlestep not enabled */ + tcg_gen_goto_tb(n); + tcg_gen_movi_i32(cpu_pc, dest); + tcg_gen_exit_tb((long) tb + n); + } else { + tcg_gen_movi_i32(cpu_pc, dest); + if (ctx->singlestep_enabled) + gen_helper_debug(); + tcg_gen_exit_tb(0); + } +======================== + +======================== + if (tb->cflags & CF_LAST_IO) + gen_io_end(); + if (env->singlestep_enabled) { + tcg_gen_movi_i32(cpu_pc, ctx.pc); + gen_helper_debug(); + } else { +========================== \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/600 b/results/classifier/gemma3:12b/debug/600 new file mode 100644 index 000000000..c9ca1284e --- /dev/null +++ b/results/classifier/gemma3:12b/debug/600 @@ -0,0 +1,2 @@ + +Have 'info mtree' accept an (optional) 'name' parameter to pick a specific address space diff --git a/results/classifier/gemma3:12b/debug/620 b/results/classifier/gemma3:12b/debug/620 new file mode 100644 index 000000000..157e1d068 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/620 @@ -0,0 +1,2 @@ + +QEMU gdbstub should add memtag support for aarch64 MTE diff --git a/results/classifier/gemma3:12b/debug/622367 b/results/classifier/gemma3:12b/debug/622367 new file mode 100644 index 000000000..c41c4d629 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/622367 @@ -0,0 +1,9 @@ + +No BIOS MPFP structure with smp=92 and more + +qemu 0.12.2, SeaBios 0.5.1, running qemu-system-x86_64.exe with option -smp. +If smp>=92 then no MP floating point structure present in 1 Mb. This may be verified by pmemsave 0 0x100000 in debugger and search for _MP_ signature in file. + +qemu 0.10.5 (bios build 05/08/09) can smp=128 (and even 255 if not hangs :). + +Host win 7 x64 RTM 7600. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/640213 b/results/classifier/gemma3:12b/debug/640213 new file mode 100644 index 000000000..804fe761c --- /dev/null +++ b/results/classifier/gemma3:12b/debug/640213 @@ -0,0 +1,24 @@ + +QEMU does not communicate properly with GDB with a 64 bit guest + +I have been trying to figure out why I cannot debug a 64 bit kernel of my own invention. + +I launch qemu-system-x86_64 with the -s -S flags, we also specify -cpu core2duo -vga std and a -hda with an ext2 FS holding our multiboot kernel and GRUB2. + +When I try to set breakpoints and "continue" in GDB (7.2) using the very latest HEAD (b6601141cd2a170dfe773987b06f716a190ea7e0) or 0.12.0 or 0.12.5 or 13.0.rc0 or 13.0.rc1, I get failures of the same nature: + +0x0000000000000000 in ?? () +(gdb) break main +Breakpoint 1 at 0x101730: file src/kernel/init.c, line 18. +(gdb) c + +Program received signal SIGTRAP, Trace/breakpoint trap. +0x0000000000000000 in ?? () +(gdb) + +Note that in this case, main lies in 64 bit mode. However, trying to break on _start yields virtually the same effect and _start is 32 bit code. + +By doing a git bisect, I managed to narrow the commit that introduced this bug to 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1. Reverting this commit on HEAD seemingly fixed the problem for both the 32 bit and 64 bit cases. +I might be doing something incorrectly on my end but this seemed to fix the problem. + +Perhaps the pertinent thing to do would be to revert 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 as it seems to do nothing but break things unless, of course, this would only break something that I am not aware of further. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/647 b/results/classifier/gemma3:12b/debug/647 new file mode 100644 index 000000000..d7b69d251 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/647 @@ -0,0 +1,302 @@ + +scsi_device_purge_requests() waits infinietly +Description of problem: +QEMU hangs typing `system_reset` in the monitor, the monitor becomes unresponsive, as does VNC. +Steps to reproduce: +1. In the guest as root: `dd if=/dev/sda ibs=2K obs=1M of=/dev/null` +2. In the host monitor: `(qemu) system_reset` +3. Attach with gdb +4. Press ^C in the unresponsive monitor +``` +Thread 1 "qemu-system-x86" received signal SIGINT, Interrupt. +0x00007ffff749796e in ppoll () from /lib64/libc.so.6 +(gdb) bt +#0 0x00007ffff749796e in ppoll () at /lib64/libc.so.6 +#1 0x00005555570e829a in ppoll () +#2 0x0000555559624473 in qemu_poll_ns (fds=0x6060000204e0, nfds=1, timeout=-1) at ../util/qemu-timer.c:336 +#3 0x0000555559651973 in fdmon_poll_wait (ctx=0x61300004d900, ready_list=0x7fffffffb200, timeout=-1) at ../util/fdmon-poll.c:80 +#4 0x00005555595f48f1 in aio_poll (ctx=0x61300004d900, blocking=true) at ../util/aio-posix.c:607 +#5 0x0000555559041dac in bdrv_do_drained_begin (bs=0x62900000a200, recursive=false, parent=0x0, ignore_bds_parents=false, poll=true) at ../block/io.c:473 +#6 0x00005555590414a3 in bdrv_drained_begin (bs=0x62900000a200) at ../block/io.c:479 +#7 0x000055555916f180 in blk_drain (blk=0x618000001080) at ../block/block-backend.c:1732 +#8 0x000055555778f140 in scsi_device_purge_requests (sdev=0x617000004d80, sense=...) at ../hw/scsi/scsi-bus.c:1638 +#9 0x0000555557842df9 in scsi_disk_reset (dev=0x617000004d80) at ../hw/scsi/scsi-disk.c:2248 +#10 0x00005555592a557e in device_transitional_reset (obj=0x617000004d80) at ../hw/core/qdev.c:1028 +#11 0x00005555592a7eb7 in resettable_phase_hold (obj=0x617000004d80, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:182 +#12 0x000055555928a2e8 in bus_reset_child_foreach (obj=0x62d0000268d8, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/bus.c:97 +#13 0x00005555592aaaac in resettable_child_foreach (rc=0x60e000026f40, obj=0x62d0000268d8, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96 +#14 0x00005555592a7b9a in resettable_phase_hold (obj=0x62d0000268d8, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173 +#15 0x00005555592a1c55 in device_reset_child_foreach (obj=0x62d000026680, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/qdev.c:366 +#16 0x00005555592aaaac in resettable_child_foreach (rc=0x60e000040a80, obj=0x62d000026680, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96 +#17 0x00005555592a7b9a in resettable_phase_hold (obj=0x62d000026680, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173 +#18 0x000055555928a2e8 in bus_reset_child_foreach (obj=0x62d0000265f8, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/bus.c:97 +#19 0x00005555592aaaac in resettable_child_foreach (rc=0x60e000026680, obj=0x62d0000265f8, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96 +#20 0x00005555592a7b9a in resettable_phase_hold (obj=0x62d0000265f8, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173 +#21 0x00005555592a1c55 in device_reset_child_foreach (obj=0x62d00001e400, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/qdev.c:366 +#22 0x00005555592aaaac in resettable_child_foreach (rc=0x60e000042300, obj=0x62d00001e400, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96 +#23 0x00005555592a7b9a in resettable_phase_hold (obj=0x62d00001e400, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173 +#24 0x000055555928a2e8 in bus_reset_child_foreach (obj=0x62200005c260, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/bus.c:97 +#25 0x00005555592aaaac in resettable_child_foreach (rc=0x60e00002e2c0, obj=0x62200005c260, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96 +#26 0x00005555592a7b9a in resettable_phase_hold (obj=0x62200005c260, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173 +#27 0x00005555592a1c55 in device_reset_child_foreach (obj=0x62200005b900, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/qdev.c:366 +#28 0x00005555592aaaac in resettable_child_foreach (rc=0x60e000030940, obj=0x62200005b900, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96 +#29 0x00005555592a7b9a in resettable_phase_hold (obj=0x62200005b900, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173 +#30 0x000055555928a2e8 in bus_reset_child_foreach (obj=0x61d00008a280, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/bus.c:97 +#31 0x00005555592aaaac in resettable_child_foreach (rc=0x60e00002e2c0, obj=0x61d00008a280, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96 +#32 0x00005555592a7b9a in resettable_phase_hold (obj=0x61d00008a280, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173 +#33 0x00005555592a1c55 in device_reset_child_foreach (obj=0x62a000006200, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/qdev.c:366 +#34 0x00005555592aaaac in resettable_child_foreach (rc=0x60e000030160, obj=0x62a000006200, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96 +#35 0x00005555592a7b9a in resettable_phase_hold (obj=0x62a000006200, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173 +#36 0x000055555928a2e8 in bus_reset_child_foreach (obj=0x60c000020a40, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/bus.c:97 +#37 0x00005555592aaaac in resettable_child_foreach (rc=0x60e00002fde0, obj=0x60c000020a40, cb=0x5555592a78e0 <resettable_phase_hold>, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:96 +#38 0x00005555592a7b9a in resettable_phase_hold (obj=0x60c000020a40, opaque=0x0, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:173 +#39 0x00005555592a6e04 in resettable_assert_reset (obj=0x60c000020a40, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:60 +#40 0x00005555592a6cb7 in resettable_reset (obj=0x60c000020a40, type=RESET_TYPE_COLD) at ../hw/core/resettable.c:45 +#41 0x00005555592a9337 in resettable_cold_reset_fn (opaque=0x60c000020a40) at ../hw/core/resettable.c:269 +#42 0x00005555592a6c35 in qemu_devices_reset () at ../hw/core/reset.c:69 +#43 0x00005555582fb4f5 in pc_machine_reset (machine=0x616000000380) at ../hw/i386/pc.c:1764 +#44 0x0000555558a58e56 in qemu_system_reset (reason=SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET) at ../softmmu/runstate.c:443 +#45 0x0000555558a5a746 in main_loop_should_exit () at ../softmmu/runstate.c:688 +#46 0x0000555558a5a57e in qemu_main_loop () at ../softmmu/runstate.c:722 +#47 0x00005555571acaef in main (argc=58, argv=0x7fffffffd8f8, envp=0x7fffffffdad0) at ../softmmu/main.c:50 +(gdb) +(gdb) fr 5 +#5 0x0000555559041dac in bdrv_do_drained_begin (bs=0x62900000a200, recursive=false, parent=0x0, ignore_bds_parents=false, poll=true) at ../block/io.c:473 +473 BDRV_POLL_WHILE(bs, bdrv_drain_poll_top_level(bs, recursive, parent)); +(gdb) p *bs +$1 = {open_flags = 24578, encrypted = false, sg = false, probed = false, force_share = false, implicit = false, drv = 0x55555b0b0c60 <bdrv_qcow2>, opaque = 0x615000015200, aio_context = 0x6130000df080, + aio_notifiers = {lh_first = 0x0}, walking_aio_notifiers = false, filename = "nvme://0000:bc:00.0/1", '\000' <repeats 4074 times>, backing_file = '\000' <repeats 4095 times>, + auto_backing_file = '\000' <repeats 4095 times>, backing_format = '\000' <repeats 15 times>, full_open_options = 0x621002ba2100, exact_filename = "nvme://0000:bc:00.0/1", '\000' <repeats 4074 times>, + backing = 0x0, file = 0x608000002ba0, bl = {request_alignment = 1, max_pdiscard = 0, pdiscard_alignment = 65536, max_pwrite_zeroes = 0, pwrite_zeroes_alignment = 65536, opt_transfer = 0, + max_transfer = 131072, max_hw_transfer = 0, min_mem_alignment = 512, opt_mem_alignment = 4096, max_iov = 1024}, supported_read_flags = 0, supported_write_flags = 0, supported_zero_flags = 260, + supported_truncate_flags = 2, node_name = "drive_nvme1", '\000' <repeats 20 times>, node_list = {tqe_next = 0x0, tqe_circ = {tql_next = 0x0, tql_prev = 0x6290000092d0}}, bs_list = {tqe_next = 0x0, + tqe_circ = {tql_next = 0x0, tql_prev = 0x6290000092e0}}, monitor_list = {tqe_next = 0x0, tqe_circ = {tql_next = 0x0, tql_prev = 0x6290000092f0}}, refcnt = 2, op_blockers = {{ + lh_first = 0x0} <repeats 16 times>}, inherits_from = 0x0, children = {lh_first = 0x608000002ba0}, parents = {lh_first = 0x608000003620}, options = 0x621000019100, explicit_options = 0x62100001a500, + detect_zeroes = BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF, backing_blocker = 0x0, total_sectors = 41943040, write_threshold_offset = 0, dirty_bitmap_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, + __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, file = 0x0, line = 0, initialized = true}, + dirty_bitmaps = {lh_first = 0x0}, wr_highest_offset = {value = 17686634496}, copy_on_read = 0, in_flight = 128, serialising_in_flight = 0, io_plugged = 0, enable_write_cache = 0, quiesce_counter = 1, + recursive_quiesce_counter = 0, write_gen = 101, reqs_lock = {locked = 0, ctx = 0x0, from_push = {slh_first = 0x0}, to_pop = {slh_first = 0x0}, handoff = 0, sequence = 0, holder = 0x0}, tracked_requests = { + lh_first = 0x7ffc251b48a0}, flush_queue = {entries = {sqh_first = 0x0, sqh_last = 0x62900000e470}}, active_flush_req = false, flushed_gen = 81, never_freeze = false} +(gdb) fr 4 +#4 0x00005555595f48f1 in aio_poll (ctx=0x61300004d900, blocking=true) at ../util/aio-posix.c:607 +607 ret = ctx->fdmon_ops->wait(ctx, &ready_list, timeout); +(gdb) p timeout +$5 = -1 +(gdb) p blocking +$6 = true +(gdb) p *ctx +$3 = {source = {callback_data = 0x0, callback_funcs = 0x0, source_funcs = 0x55555b42d900 <aio_source_funcs>, ref_count = 2, context = 0x60f000000400, priority = 0, flags = 33, source_id = 1, + poll_fds = 0x615000001790 = {0x60d000000860}, prev = 0x0, next = 0x61300004d3c0, name = 0x602000010a10 "aio-context", priv = 0x619000003830}, lock = {m = {lock = {__data = {__lock = 0, __count = 0, + __owner = 0, __nusers = 0, __kind = 1, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 16 times>, "\001", '\000' <repeats 22 times>, __align = 0}, + file = 0x0, line = 0, initialized = true}}, aio_handlers = {lh_first = 0x60d000000860}, deleted_aio_handlers = {lh_first = 0x0}, notify_me = 2, list_lock = {count = 4}, bh_list = {slh_first = 0x0}, + bh_slice_list = {sqh_first = 0x0, sqh_last = 0x61300004d9b8}, notified = false, notifier = {rfd = 7, wfd = 7, initialized = true}, scheduled_coroutines = {slh_first = 0x0}, co_schedule_bh = 0x604000001110, + thread_pool = 0x0, tlg = {tl = {0x60b00000a1d0, 0x60b00000a280, 0x60b00000a330, 0x60b00000a3e0}}, external_disable_cnt = 0, poll_disable_cnt = 0, poll_ns = 0, poll_max_ns = 0, poll_grow = 0, + poll_shrink = 0, aio_max_batch = 0, poll_aio_handlers = {lh_first = 0x60d000000860}, poll_started = false, epollfd = 6, fdmon_ops = 0x55555a4ebbc0 <fdmon_poll_ops>} +(gdb) p ctx->bh_list +$8 = {slh_first = 0x0} +(gdb) p ctx->bh_slice_list +$9 = {sqh_first = 0x0, sqh_last = 0x61300004d9b8} +(gdb) p *ctx->bh_slice_list.sqh_last +$11 = (struct BHListSlice *) 0x0 +(gdb) p ctx->tlg +$12 = {tl = {0x60b00000a1d0, 0x60b00000a280, 0x60b00000a330, 0x60b00000a3e0}} +(gdb) p timerlist_deadline_ns(ctx->tlg.tl[0]) +$14 = -1 +(gdb) p timerlist_deadline_ns(ctx->tlg.tl[1]) +$15 = -1 +(gdb) p timerlist_deadline_ns(ctx->tlg.tl[2]) +$16 = -1 +(gdb) p timerlist_deadline_ns(ctx->tlg.tl[3]) +$17 = -1 +``` +What I see is: +- timerlistgroup_deadline_ns() -> -1 +- aio_compute_timeout() -> -1 +- aio_poll() -> -1 + +So scsi_device_purge_requests() waits indefinitively. +Additional information: +``` +../configure --enable-trace-backends=log --disable-docs --enable-debug --extra-cflags='-ggdb -fPIE' --disable-user --disable-tools --target-list=x86_64-softmmu --cc=clang --cxx=clang++ --enable-sanitizers --disable-vhost-user +qemu 6.1.0 + + Directories + Install prefix: /usr/local + BIOS directory: share/qemu + firmware path: /usr/local/share/qemu-firmware + binary directory: bin + library directory: lib + module directory: lib/qemu + libexec directory: libexec + include directory: include + config directory: /usr/local/etc + local state directory: /usr/local/var + Manual directory: share/man + Doc directory: /usr/local/share/doc + Build directory: /home/philmd/qemu/build + Source path: /home/philmd/qemu + GIT submodules: ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp + + Host binaries + git: git + make: make + python: /usr/bin/python3 (version: 3.9) + sphinx-build: NO + gdb: /usr/bin/gdb + genisoimage: /usr/bin/mkisofs + smbd: "/usr/sbin/smbd" + + Configurable features + Documentation: NO + system-mode emulation: YES + user-mode emulation: NO + block layer: YES + Install blobs: YES + module support: NO + fuzzing support: NO + Audio drivers: oss + Trace backends: log + QOM debugging: YES + vhost-kernel support: YES + vhost-net support: YES + vhost-crypto support: NO + vhost-scsi support: YES + vhost-vsock support: YES + vhost-user support: NO + vhost-user-blk server support: NO + vhost-user-fs support: NO + vhost-vdpa support: YES + build guest agent: YES + + Compilation + host CPU: x86_64 + host endianness: little + C compiler: clang + Host C compiler: clang + C++ compiler: clang++ + CFLAGS: -O0 -g + CXXFLAGS: -O0 -g + QEMU_CFLAGS: -fsanitize=undefined -fsanitize=address -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -ggdb -fPIE -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong + QEMU_LDFLAGS: -Wl,--warn-common -fsanitize=undefined -fsanitize=address -Wl,-z,relro -Wl,-z,now -m64 -ggdb -fPIE -fstack-protector-strong + profiler: NO + link-time optimization (LTO): NO + PIE: YES + static build: NO + malloc trim support: YES + membarrier: NO + debug stack usage: NO + mutex debugging: YES + memory allocator: system + avx2 optimization: NO + avx512f optimization: NO + gprof enabled: NO + gcov: NO + thread sanitizer: NO + CFI support: NO + strip binaries: NO + sparse: NO + mingw32 support: NO + x86_64 tests: x86_64-linux-gnu-gcc via debian-amd64-cross + + Targets and accelerators + KVM support: YES + HAX support: NO + HVF support: NO + WHPX support: NO + NVMM support: NO + Xen support: NO + TCG support: YES + TCG backend: native (x86_64) + TCG plugins: YES + TCG debug enabled: YES + target list: x86_64-softmmu + default devices: YES + out of process emulation: YES + + Block layer support + coroutine backend: ucontext + coroutine pool: YES + Block whitelist (rw): + Block whitelist (ro): + Use block whitelist in tools: NO + VirtFS support: NO + build virtiofs daemon: NO + Live block migration: YES + replication support: YES + bochs support: YES + cloop support: YES + dmg support: YES + qcow v1 support: YES + vdi support: YES + vvfat support: YES + qed support: YES + parallels support: YES + FUSE exports: NO + + Crypto + TLS priority: "NORMAL" + GNUTLS support: YES + GNUTLS crypto: YES + libgcrypt: NO + nettle: NO + crypto afalg: NO + rng-none: NO + Linux keyring: YES + + Dependencies + SDL support: NO + SDL image support: NO + GTK support: NO + pixman: YES + VTE support: NO + slirp support: internal + libtasn1: YES + PAM: NO + iconv support: YES + curses support: YES + virgl support: NO + curl support: NO + Multipath support: NO + VNC support: YES + VNC SASL support: YES + VNC JPEG support: YES + VNC PNG support: NO + brlapi support: NO + vde support: NO + netmap support: NO + Linux AIO support: NO + Linux io_uring support: NO + ATTR/XATTR support: YES + RDMA support: NO + PVRDMA support: NO + fdt support: internal + libcap-ng support: NO + bpf support: NO + spice support: NO + rbd support: NO + xfsctl support: NO + smartcard support: NO + U2F support: NO + libusb: NO + usb net redir: NO + OpenGL support: NO + GBM: NO + libiscsi support: NO + libnfs support: NO + seccomp support: NO + GlusterFS support: NO + TPM support: YES + libssh support: NO + lzo support: NO + snappy support: NO + bzip2 support: NO + lzfse support: NO + zstd support: NO + NUMA host support: NO + libxml2: NO + capstone: internal + libpmem support: NO + libdaxctl support: NO + libudev: NO + FUSE lseek: NO + ``` diff --git a/results/classifier/gemma3:12b/debug/654 b/results/classifier/gemma3:12b/debug/654 new file mode 100644 index 000000000..f3d898460 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/654 @@ -0,0 +1,24 @@ + +Strace Log Output Mangled +Description of problem: +The syscall log entries from the strace logging capability can be interrupted by other log messages before the full syscall line is +complete. +This makes parsing the strace syscall lines from the log output difficult. +Steps to reproduce: +1. Run the supplied command with a simple dynamically linked binary, or a binary that performs mmaps +2. Notice that the strace 'mmap' syscall log entries in the trace file are interrupted by the page log output +Additional information: +I have attached an example log from a dynamically linked 'hello world' binary, which demonstrates the bug in the mmap syscall strace entries. [output.trace](/uploads/88c83273582d00241fbf95af735dcc61/output.trace) + + +I believe this bug caused by a couple of things: +Firstly, in the linux-user/syscall.c file: the strace syscall entry is not output atomically, but instead split across two calls: +The first half is at `print_syscall`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13153 +And the return value (and new line) is printed in `print_syscall_ret`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13160 + +In the case of the mmap syscall, the function `log_page_dump` is called between these two functions resulting in the mangled log output: +https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/mmap.c#L633 +There may be other syscalls that behave similarly, but this was noticed due to the mmap behavior. + + +Internally to the `print_syscall` and `print_syscall_ret` functions, `qemu_log` is called multiple times to compose the full log entry, and it seems that it is inside `qemu_log` that the logfile lock is obtained and dropped - so theoretically another thread can output to the log during the printing of a single syscall entry between these `qemu_log` calls. I do not know if this actually happens in practice besides the mmap scenario described above. diff --git a/results/classifier/gemma3:12b/debug/657006 b/results/classifier/gemma3:12b/debug/657006 new file mode 100644 index 000000000..cfc193af9 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/657006 @@ -0,0 +1,45 @@ + +arm v7M - svc insn doesn't trigger PendSV handler + +The svc instruction doesn't work as expected. + +-> qemu 0.13.0 rc1 (git) + +Test : demo with freeRTOS (for example FreeRTOS-6.0.5/Demo/CORTEX_LM3S811_GCC) with the card lm3s811evb. + +If we start the scheduler, it will call that function (__attribute__ (( naked ))) : + +void vPortStartFirstTask( void ) + +{ + + __asm volatile( + + " ldr r0, =0xE000ED08 \n" /* Use the NVIC offset register to locate the stack. */ + + " ldr r0, [r0] \n" + + " ldr r0, [r0] \n" + + " msr msp, r0 \n" /* Set the msp back to the start of the stack. */ + + " svc 0 \n" /* System call to start first task. */ + + ); + +} + +The 4 first lines in asm work fine. The scv 0 call will rise the right interrupt in qemu (line 151, in arm_gic.c, best_irq = 15). However, it will never call the PendSV Handler (xPortPendSVHandler here). This function is recorded in the nvic vector. +Next, (after the svc), the processor will execute the line after in code (this is a naked function) so the next function written after vPortStartFirstTask in the code. + + +command line : +console 1 : qemu-system-arm -M lm3s6965evb -kernel gcc/RTOSDemo.axf -s -S +console 2 : arm-none-eabi-gdb -ex "target remote localhost:1234" gcc/RTOSDemo.axf + +arm-none-eabi from http://www.codesourcery.com/sgpp/lite/arm/portal/release1294 +Same error with another project with arm-elf + +processor : arm cortex m3 + +host : gentoo (2.6.35-r9) (without kqemu) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/661696 b/results/classifier/gemma3:12b/debug/661696 new file mode 100644 index 000000000..65663387d --- /dev/null +++ b/results/classifier/gemma3:12b/debug/661696 @@ -0,0 +1,29 @@ + +incomplete emulation of fstenv under TCG + +Steps to reproduce: + +1) Install Windows (tried XP and 7) in qemu (tried qemu without kvm and qemu-kvm). + +2) Get OllyDbg ( http://ollydbg.de/odbg200.zip ). + +3) Use some Metasploit-encoded file, example included. + +It is not a virus! + +File was generated with Metasploit, command (if i remember it right): `msfpayload windows/exec cmd=notepad R | msfencode -e x86/shikata_ga_nai -t exe -o cmd_exec_notepad.shikata_ga_nai.exe`. + +4) Launch the file under Windows in qemu, make sure it opens a notepad. + +5) Open file under OllyDbg, run (F9) it there. It opens a notpad. Close OllyDbg. + +6) Open file under OllyDbg, trace over (Ctrl+F12) it there. It fails with `Access violation when writing to [some address]`. +Command: 316A 13, XOR DWORD PTR DS:[EDX+13],EBP + +Under native Windows, the trace over command works fine. + +Under VMware the trace works fine. +Under VirtualBox it also fails (checked in the spring). + +$ qemu-kvm --version +QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/675 b/results/classifier/gemma3:12b/debug/675 new file mode 100644 index 000000000..986a73000 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/675 @@ -0,0 +1,11 @@ + +Attaching WinDbg to a Windows guest on Windows host causes hang +Description of problem: +Attempting to attach WinDbg to a Windows guest on a Windows host causes qemu to lockup while using real serial ports. This has been an issue for some time (years if I'm remembering correctly) I just haven't reported it. +Steps to reproduce: +1. Enable debug in Windows guest +2. Create a DB9 between 2 COM ports +3. Power guest +4. Attach WinDbg to 2nd COM port not in use by the guest +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/696094 b/results/classifier/gemma3:12b/debug/696094 new file mode 100644 index 000000000..1c101eb8d --- /dev/null +++ b/results/classifier/gemma3:12b/debug/696094 @@ -0,0 +1,39 @@ + +TI Stellaris lm3s811evb (ARM Cortex-M3) : Systick interrupt not working + +I've tried to create a small project that uses the CMSIS as base library. +The problem is that the SysTick_interrupt_handler() doesn't get executed when the systick event is detected in QEMU. Furthermore, it seems asif QEMU gets stuck in an endless loop. QEMU doesn't respond to Ctrl-C on the command line and the GDB session also stalls. 'kill -9' is the only way to stop QEMU. + +It seems asif the initialisation of the NVIC works fine. I've traced the function calls in QEMU as follows: +stellaris.c: stellaris_init() - Perform generic armv7 init: armv7m_init() + armv7m.c: armv7m_init() - Create and init the nvic: + nvic = qdev_create(NULL, "armv7m_nvic"); + env->nvic = nvic; + qdev_init_nofail(nvic); + - Configure the programmable interrupt controller: + Call: arm_pic_init_cpu() + qemu_allocate_irqs(arm_pic_cpu_handler) + - Initialise 64 interrupt structures. + +The following call sequence is observed when the systick event occur: +armv7m_nvic.c: systick_timer_tick(): set pending interrupt +armv7m_nvic.c: armv7m_nvic_set_pending() for irq:15 + arm_gic.c: gic_set_pending_private(): GIC_SET_PENDING(15,) + arm_gic.c: gic_update() - Raise IRQ with qemu_set_irq() + irq.c: eqmu_set_irq() - Call the irq->handler + -- I assume the irq handler is 'arm_pic_cpu_handler()', + since that was passed as the parameter when + qemu_allocate_irqs() was called in ... + arm_pic.c: arm_pic_cpu_handler() - After evaluation, call cpu_interrupt() + exec.c: cpu_interrupt() is called. + +The tools that were used during the testing of this project: + GCC: Codesourcery ARM eabi 2010q3 + QEMU: Checked out on 31/12/2010 - Last commit: 0fcec41eec0432c77645b4a407d3a3e030c4abc4 +The project files are attached, for reproducing of the errors. + Note: The CMSIS wants to perform byte accesses to the NVIC. For the Cortex-M3, unaligned 8 bit and 16 bit accesses are allowed. The current QEMU implementation doesn't yet cater for it. As a work around, updated versions of +arm_gic.c armv7m_nvic.h armv7m_nvic.c is also included. + +Launch project with: go_gdb.sh +Attach debugger with: arm-none-eabi-gdbtui --command=gdbCommands_tui +(s = step, n = next, c = continue, Ctrl-C = stop, print <variable> to look at variable contents) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/696834 b/results/classifier/gemma3:12b/debug/696834 new file mode 100644 index 000000000..8eb5be2e7 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/696834 @@ -0,0 +1,32 @@ + +FP exception reporting not working on NetBSD host + +I recognize that NetBSD is not one of the officially supported host OS. However, qemu 0.13.0 is available in the NetBSD pkgsrc collection, and works quite well. Well, with one exception (pun intended): It seems that Floating Point exceptions don't get reported properly. + +The following code-snippet demonstrates the problem: + + +volatile int flt_signal = 0; + +static sigjmp_buf sigfpe_flt_env; +static void +sigfpe_flt_action(int signo, siginfo_t *info, void *ptr) +{ + flt_signal++; +} + +void trigger(void) +{ + struct sigaction sa; + double d = strtod("0", NULL); + + if (sigsetjmp(sigfpe_flt_env, 0) == 0) { + sa.sa_flags = SA_SIGINFO; + sa.sa_sigaction = sigfpe_flt_action; + sigemptyset(&sa.sa_mask); + sigaction(SIGFPE, &sa, NULL); + fpsetmask(FP_X_INV|FP_X_DZ|FP_X_OFL|FP_X_UFL|FP_X_IMP); + printf("%g\n", 1 / d); + } + printf("FPE signal handler invoked %d times.\n"); +} \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/698 b/results/classifier/gemma3:12b/debug/698 new file mode 100644 index 000000000..e113bccba --- /dev/null +++ b/results/classifier/gemma3:12b/debug/698 @@ -0,0 +1,359 @@ + +linux-user: emulated process reading /proc/self/mem doesn't see guest view of memory map +Description of problem: +QEMU user-mode emulation of a 32-bit guest on a 64-bit host doesn't seem to emulate `/proc/self/mem` (or `/proc/$pid/mem`) correctly. Based on the contents of `/proc/self/maps`, there seems to be some sort of address translation happening that `/proc/self/mem` doesn't honor. + +The following source file: + +```c +#include <fcntl.h> +#include <inttypes.h> +#include <stdbool.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <sys/wait.h> + +static const char string[] = "Hello, world!\n"; + +static bool copy_to_stdout(const char *path) +{ + bool success = false; + + int fd = open(path, O_RDONLY); + if (fd < 0) { + perror("open"); + return false; + } + + char buf[16 * 1024]; + while (true) { + ssize_t bytes_read = read(fd, buf, sizeof(buf)); + if (bytes_read == 0) { + success = true; + goto out; + } else if (bytes_read < 0) { + perror("read"); + goto out; + } + ssize_t bytes_written = 0; + while (bytes_written < bytes_read) { + ssize_t ret = write(STDOUT_FILENO, buf + bytes_written, + bytes_read - bytes_written); + if (ret < 0) { + perror("write"); + goto out; + } + bytes_written += ret; + } + } + +out: + close(fd); + return success; +} + +static bool dump_maps(void) +{ + printf("Maps read by self:\n"); + fflush(stdout); + if (!copy_to_stdout("/proc/self/maps")) + return false; + + printf("\nMaps read by child process:\n"); + fflush(stdout); + pid_t pid = fork(); + if (pid < 0) { + perror("fork"); + return false; + } + if (pid == 0) { + char parent_maps[32]; + sprintf(parent_maps, "/proc/%u/maps", (unsigned int)getppid()); + if (copy_to_stdout(parent_maps)) + _exit(EXIT_SUCCESS); + else + _exit(EXIT_FAILURE); + } + int wstatus; + if (waitpid(pid, &wstatus, 0) < 0 || + !WIFEXITED(wstatus) || WEXITSTATUS(wstatus) != EXIT_SUCCESS) + return false; + + printf("\n"); + return true; +} + +int main(void) +{ + if (!dump_maps()) + return EXIT_FAILURE; + + int fd = open("/proc/self/mem", O_RDONLY); + if (fd < 0) { + perror("open: /proc/self/mem"); + return EXIT_FAILURE; + } + + char buf[sizeof(string)]; + printf("Reading %zu bytes from %p (%" PRIuPTR ") to %p of PID %u\n", + sizeof(buf), string, (uintptr_t)string, buf, + (unsigned int)getpid()); + fflush(stdout); + + if (pread(fd, buf, sizeof(buf), (uintptr_t)string) < 0) { + perror("pread: /proc/self/mem"); + return EXIT_FAILURE; + } + + if (memcmp(buf, string, sizeof(buf)) != 0) { + fprintf(stderr, "buffer doesn't match\n"); + return EXIT_FAILURE; + } + + return EXIT_SUCCESS; +} +``` + +when compiled for 32-bit ARM produces the following output: + +``` +Maps read by self: +10000-7c000 r-xp 00000000 00:19 8275924 /home/osandov/repro +7c000-8b000 ---p 00000000 00:00 0 +8b000-8c000 r--p 0006b000 00:19 8275924 /home/osandov/repro +8c000-8d000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +8d000-b0000 rw-p 00000000 00:00 0 +3ffff000-40000000 r-xp 00000000 00:00 0 +40000000-40001000 ---p 00000000 00:00 0 +40001000-40801000 rw-p 00000000 00:00 0 [stack] + +Maps read by child process: +00010000-00020000 ---p 00000000 00:00 0 +00020000-0008c000 r--p 00000000 00:19 8275924 /home/osandov/repro +0008c000-0009b000 ---p 00000000 00:00 0 +0009b000-0009c000 r--p 0006b000 00:19 8275924 /home/osandov/repro +0009c000-0009d000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +0009d000-000c0000 rw-p 00000000 00:00 0 +000c0000-4000f000 ---p 00000000 00:00 0 +4000f000-40010000 r--p 00000000 00:00 0 +40010000-40011000 ---p 00000000 00:00 0 +40011000-40811000 rw-p 00000000 00:00 0 +40811000-100000000 ---p 00000000 00:00 0 +100000000-100001000 r--p 00000000 00:00 0 +5636dd7a2000-5636dd8a4000 r--p 00000000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636dd8a4000-5636ddb13000 r-xp 00102000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddb13000-5636ddf69000 r--p 00371000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddf6a000-5636ddfe7000 r--p 007c7000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddfe7000-5636ddff3000 rw-p 00844000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddff3000-5636de010000 rw-p 00000000 00:00 0 +5636df67b000-5636df80c000 rw-p 00000000 00:00 0 [heap] +7f3008000000-7f300ffff000 rwxp 00000000 00:00 0 +7f300ffff000-7f3010000000 ---p 00000000 00:00 0 +7f3010000000-7f3010021000 rw-p 00000000 00:00 0 +7f3010021000-7f3014000000 ---p 00000000 00:00 0 +7f3017119000-7f301719a000 rw-p 00000000 00:00 0 +7f301719a000-7f301719b000 ---p 00000000 00:00 0 +7f301719b000-7f30179a1000 rw-p 00000000 00:00 0 +7f30179a1000-7f30179a3000 r--p 00000000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179a3000-7f30179a9000 r-xp 00002000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179a9000-7f30179ab000 r--p 00008000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179ab000-7f30179ac000 r--p 00009000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179ac000-7f30179ad000 rw-p 0000a000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179ad000-7f30179be000 r--p 00000000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f30179be000-7f3017a32000 r-xp 00011000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a32000-7f3017a49000 r--p 00085000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a49000-7f3017a4a000 ---p 0009c000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a4a000-7f3017a4c000 r--p 0009c000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a4c000-7f3017a4d000 rw-p 0009e000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a4d000-7f3017a56000 r--p 00000000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a56000-7f3017a69000 r-xp 00009000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a69000-7f3017a93000 r--p 0001c000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a93000-7f3017a95000 r--p 00045000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a95000-7f3017a96000 rw-p 00047000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a96000-7f3017a98000 rw-p 00000000 00:00 0 +7f3017a98000-7f3017aa4000 r--p 00000000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017aa4000-7f3017ac5000 r-xp 0000c000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017ac5000-7f3017adb000 r--p 0002d000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017adb000-7f3017adc000 ---p 00043000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017adc000-7f3017ade000 r--p 00043000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017ade000-7f3017adf000 rw-p 00045000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017adf000-7f3017ae2000 r--p 00000000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017ae2000-7f3017aee000 r-xp 00003000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017aee000-7f3017af2000 r--p 0000f000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af2000-7f3017af3000 ---p 00013000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af3000-7f3017af4000 r--p 00013000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af4000-7f3017af5000 rw-p 00014000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af5000-7f3017b06000 r--p 00000000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017b06000-7f3017b3b000 r-xp 00011000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017b3b000-7f3017c72000 r--p 00046000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017c72000-7f3017c76000 r--p 0017c000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017c76000-7f3017c77000 rw-p 00180000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017c77000-7f3017c79000 r--p 00000000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c79000-7f3017c7d000 r-xp 00002000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c7d000-7f3017c97000 r--p 00006000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c97000-7f3017c98000 r--p 0001f000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c98000-7f3017c99000 rw-p 00020000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c99000-7f3017cc2000 r--p 00000000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017cc2000-7f3017d60000 r-xp 00029000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017d60000-7f3017dba000 r--p 000c7000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017dba000-7f3017dc4000 r--p 00120000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017dc4000-7f3017dce000 rw-p 0012a000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017dce000-7f3017dd0000 r--p 00000000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd0000-7f3017dd2000 r-xp 00002000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd2000-7f3017dd3000 r--p 00004000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd3000-7f3017dd4000 r--p 00004000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd4000-7f3017dd5000 rw-p 00005000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd5000-7f3017dd7000 rw-p 00000000 00:00 0 +7f3017dd7000-7f3017dd9000 r--p 00000000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017dd9000-7f3017e2f000 r-xp 00002000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e2f000-7f3017e4c000 r--p 00058000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e4c000-7f3017e4d000 r--p 00074000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e4d000-7f3017e4e000 rw-p 00075000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e4e000-7f3017e74000 r--p 00000000 00:19 2549806 /usr/lib/libc-2.33.so +7f3017e74000-7f3017fbf000 r-xp 00026000 00:19 2549806 /usr/lib/libc-2.33.so +7f3017fbf000-7f301800b000 r--p 00171000 00:19 2549806 /usr/lib/libc-2.33.so +7f301800b000-7f301800e000 r--p 001bc000 00:19 2549806 /usr/lib/libc-2.33.so +7f301800e000-7f3018011000 rw-p 001bf000 00:19 2549806 /usr/lib/libc-2.33.so +7f3018011000-7f301801a000 rw-p 00000000 00:00 0 +7f301801a000-7f3018021000 r--p 00000000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018021000-7f3018030000 r-xp 00007000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018030000-7f3018034000 r--p 00016000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018034000-7f3018035000 ---p 0001a000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018035000-7f3018036000 r--p 0001a000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018036000-7f3018037000 rw-p 0001b000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018037000-7f301803b000 rw-p 00000000 00:00 0 +7f301803b000-7f301803e000 r--p 00000000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f301803e000-7f3018050000 r-xp 00003000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018050000-7f3018053000 r--p 00015000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018053000-7f3018054000 ---p 00018000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018054000-7f3018055000 r--p 00018000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018055000-7f3018056000 rw-p 00019000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018056000-7f3018065000 r--p 00000000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018065000-7f30180ff000 r-xp 0000f000 00:19 2549819 /usr/lib/libm-2.33.so +7f30180ff000-7f3018197000 r--p 000a9000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018197000-7f3018198000 ---p 00141000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018198000-7f3018199000 r--p 00141000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018199000-7f301819a000 rw-p 00142000 00:19 2549819 /usr/lib/libm-2.33.so +7f301819a000-7f3018233000 r--p 00000000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f3018233000-7f3018333000 r-xp 00099000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f3018333000-7f301839f000 r--p 00199000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f301839f000-7f30183ac000 r--p 00204000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f30183ac000-7f30183ad000 rw-p 00211000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f30183ad000-7f30183b2000 rw-p 00000000 00:00 0 +7f30183b2000-7f30183e6000 r--p 00000000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f30183e6000-7f3018508000 r-xp 00034000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f3018508000-7f301859d000 r--p 00156000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f301859d000-7f301859e000 ---p 001eb000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f301859e000-7f30185af000 r--p 001eb000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f30185af000-7f30185b1000 rw-p 001fc000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f30185b1000-7f30185b3000 rw-p 00000000 00:00 0 +7f30185b3000-7f30185b5000 r--p 00000000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b5000-7f30185b7000 r-xp 00002000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b7000-7f30185b8000 r--p 00004000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b8000-7f30185b9000 r--p 00004000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b9000-7f30185ba000 rw-p 00005000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185ba000-7f30185d7000 r--p 00000000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30185d7000-7f3018664000 r-xp 0001d000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f3018664000-7f30186ec000 r--p 000aa000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ec000-7f30186ed000 ---p 00132000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ed000-7f30186ee000 r--p 00132000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ee000-7f30186ef000 rw-p 00133000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ef000-7f30186f0000 rw-p 00000000 00:00 0 +7f30186f0000-7f30186f2000 r--p 00000000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f2000-7f30186f4000 r-xp 00002000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f4000-7f30186f5000 r--p 00004000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f5000-7f30186f6000 r--p 00004000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f6000-7f30186f7000 rw-p 00005000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f7000-7f30186fa000 r--p 00000000 00:19 2549855 /usr/lib/librt-2.33.so +7f30186fa000-7f30186fe000 r-xp 00003000 00:19 2549855 /usr/lib/librt-2.33.so +7f30186fe000-7f3018700000 r--p 00007000 00:19 2549855 /usr/lib/librt-2.33.so +7f3018700000-7f3018701000 r--p 00008000 00:19 2549855 /usr/lib/librt-2.33.so +7f3018701000-7f3018702000 rw-p 00009000 00:19 2549855 /usr/lib/librt-2.33.so +7f3018702000-7f3018705000 r--p 00000000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f3018705000-7f3018713000 r-xp 00003000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f3018713000-7f3018719000 r--p 00011000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f3018719000-7f301871a000 ---p 00017000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f301871a000-7f301871b000 r--p 00017000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f301871b000-7f301871c000 rw-p 00018000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f301871c000-7f301871e000 rw-p 00000000 00:00 0 +7f301871e000-7f301871f000 r--p 00000000 00:19 2549795 /usr/lib/ld-2.33.so +7f301871f000-7f3018743000 r-xp 00001000 00:19 2549795 /usr/lib/ld-2.33.so +7f3018743000-7f301874c000 r--p 00025000 00:19 2549795 /usr/lib/ld-2.33.so +7f301874c000-7f301874e000 r--p 0002d000 00:19 2549795 /usr/lib/ld-2.33.so +7f301874e000-7f3018750000 rw-p 0002f000 00:19 2549795 /usr/lib/ld-2.33.so +7ffc5c8f6000-7ffc5c917000 rw-p 00000000 00:00 0 [stack] +7ffc5c935000-7ffc5c939000 r--p 00000000 00:00 0 [vvar] +7ffc5c939000-7ffc5c93b000 r-xp 00000000 00:00 0 [vdso] +ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] + +Reading 15 bytes from 0x6377c (407420) to 0x40800638 of PID 278331 +buffer doesn't match +``` + +The program is trying to read from 0x6377c, which according to the emulated maps is in this mapping: + +``` +10000-7c000 r-xp 00000000 00:19 8275924 /home/osandov/repro +``` + +but on the host, it's mapped differently: + +``` +00020000-0008c000 r--p 00000000 00:19 8275924 /home/osandov/repro +``` + +When using `qemu-arm-static` (version `6.1.0 (Debian 1:6.1+dfsg-6)`) via `binfmt_misc`, I also saw a case where the address isn't mapped in the host at all: + +``` +Maps read by self: +10000-7c000 r-xp 00000000 00:19 8275924 /home/osandov/repro +7c000-8b000 ---p 00000000 00:00 0 +8b000-8c000 r--p 0006b000 00:19 8275924 /home/osandov/repro +8c000-8d000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +8d000-b0000 rw-p 00000000 00:00 0 +40000000-40001000 ---p 00000000 00:00 0 +40001000-40801000 rw-p 00000000 00:00 0 [stack] + +Maps read by child process: +00400000-00401000 r--p 00000000 00:19 297 /usr/bin/qemu-arm-static +00401000-00769000 r-xp 00001000 00:19 297 /usr/bin/qemu-arm-static +00769000-00abe000 r--p 00369000 00:19 297 /usr/bin/qemu-arm-static +00abe000-00c58000 r--p 006bd000 00:19 297 /usr/bin/qemu-arm-static +00c58000-00cd3000 rw-p 00857000 00:19 297 /usr/bin/qemu-arm-static +00cd3000-00cf7000 rw-p 00000000 00:00 0 +0253c000-0268e000 rw-p 00000000 00:00 0 [heap] +42645000-42655000 ---p 00000000 00:00 0 +42655000-426c1000 r--p 00000000 00:19 8275924 /home/osandov/repro +426c1000-426d0000 ---p 00000000 00:00 0 +426d0000-426d1000 r--p 0006b000 00:19 8275924 /home/osandov/repro +426d1000-426d2000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +426d2000-426f5000 rw-p 00000000 00:00 0 +426f5000-82645000 ---p 00000000 00:00 0 +82645000-82646000 ---p 00000000 00:00 0 +82646000-82e46000 rw-p 00000000 00:00 0 +82e46000-142635000 ---p 00000000 00:00 0 +142635000-142636000 r--p 00000000 00:00 0 +7f5584000000-7f558bfff000 rwxp 00000000 00:00 0 +7f558bfff000-7f558c000000 ---p 00000000 00:00 0 +7f558c000000-7f558c021000 rw-p 00000000 00:00 0 +7f558c021000-7f5590000000 ---p 00000000 00:00 0 +7f55929b5000-7f5592a36000 rw-p 00000000 00:00 0 +7f5592a36000-7f5592a37000 ---p 00000000 00:00 0 +7f5592a37000-7f5593237000 rw-p 00000000 00:00 0 +7ffc4971a000-7ffc4973b000 rw-p 00000000 00:00 0 [stack] +7ffc497fa000-7ffc497fe000 r--p 00000000 00:00 0 [vvar] +7ffc497fe000-7ffc49800000 r-xp 00000000 00:00 0 [vdso] +ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] + +Reading 15 bytes from 0x6377c (407420) to 0x40800648 of PID 278443 +pread: /proc/self/mem: Input/output error +``` +Steps to reproduce: +1. Download statically-linked ARM [reproducer](/uploads/5563ad67d01f0ec4a10f27d1967216c4/repro). +2. Run `qemu-arm ./repro`. +Additional information: +I encountered this when trying out a CI system that uses QEMU user-mode emulation for 32-bit ARM builds. My project is a debugger that uses `/proc/self/mem`, and a test case tripped over this. See https://github.com/osandov/drgn/pull/126. + +This also seems to happen with a i386 guest, but not with an aarch64 guest, so I'm assuming that it's a 32-bit guest issue. diff --git a/results/classifier/gemma3:12b/debug/700276 b/results/classifier/gemma3:12b/debug/700276 new file mode 100644 index 000000000..e5af86c7c --- /dev/null +++ b/results/classifier/gemma3:12b/debug/700276 @@ -0,0 +1,32 @@ + +QEMU crashed when GDB request a big size variable information + +Hello, +My host is Fedora 13. My QEMU version is 0.13.0, I use QEMU with GDB to debug Linux kernel(Version 2.6.36.2). + +I use QEMU like this:"qemu -s -S -kernel build/arch/i386/boot/bzImage -hda /dev/zero" +When GDB connected with QEMU, and use gdb command print to look big size variable, the qemu is crash down. for example, when I look a task_struct variable 'init_task'(print init_task ), the qemu produce the below message and exit. + +*** stack smashing detected ***: qemu terminated +======= Backtrace: ========= +/lib/libc.so.6(__fortify_fail+0x4d)[0x78a31d] +/lib/libc.so.6[0x78a2ca] +qemu[0x8059e21] +qemu[0x805a0cf] +qemu[0x80d12a1] +qemu[0x8189cb8] +qemu[0x818c3b0] +/lib/libc.so.6(__libc_start_main+0xe6)[0x6a8cc6] +............... +adbf7000-adbf8000 rw-p 00000000 00:00 0 +adbf8000-ae3f8000 rw-p 00000000 00:00 0 +ae3f8000-ae742000 rw-p 00000000 00:00 0 +ae742000-ae762000 rw-p 00000000 00:00 0 +ae762000-ae764000 rw-p 00000000 00:00 0 +ae764000-ae784000 rw-p 00000000 00:00 0 +ae784000-ae786000 rw-p 00000000 00:00 0 +ae786000-b6786000 rw-p 00000000 00:00 0 +b6786000-b7894000 rw-p 00000000 00:00 0 +b78aa000-b78ab000 rw-p 00000000 00:00 0 +bfe95000-bfeaa000 rw-p 00000000 00:00 0 [stack] +已放弃 (core dumped) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/714 b/results/classifier/gemma3:12b/debug/714 new file mode 100644 index 000000000..cc30003e5 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/714 @@ -0,0 +1,44 @@ + +Command line arguments are not passed correctly with user-space semihosting +Description of problem: +The emulated process always receives a value of 1 for `argc`, with `argv[0]` returning seemingly random characters (in Ubuntu packaged qemu 5.2), but correlating with command-line input (output below from master built qemu 6.1): +``` +$ qemu-arm -cpu cortex-m7 ./a.out 123 test +argc: 1 +argv: + - @@@ + +$ qemu-arm -cpu cortex-m7 ./a.out +argc: 1 +argv: + [0] @ +``` +Steps to reproduce: +1. Compile the following program with [ARM embedded toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads): +```cpp +#include <iostream> + +int main(int argc, char* argv[]) { + std::cout << "argc: " << argc << "\n"; + std::cout << "argv: \n"; + + for (int i = 0; i < argc; i++) + std::cout << " [" << i << "] " << argv[i] << "\n"; + return 0; +} +``` + +``` +$ $CXX --version +arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release) +Copyright (C) 2020 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +$ $CXX main.cpp --specs=rdimon.specs -mcpu=cortex-m7 +``` + +2. Run in user-space (semihosted): +``` +$ qemu-arm -cpu cortex-m7 ./a.out +``` diff --git a/results/classifier/gemma3:12b/debug/729 b/results/classifier/gemma3:12b/debug/729 new file mode 100644 index 000000000..3447c93a7 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/729 @@ -0,0 +1,35 @@ + +Environment variables are not passed with user-space semihosting +Description of problem: +Environment variables are not passed to the emulated process, either inherited (as I might expect it to work in user-space?) or by specifying the values through the QEMU command-line. Note that setting the environment variable from within the app before calling `getenv` does work, so it isn't just a case of some system no-ops for the platform. +Steps to reproduce: +1. Compile the following program with [ARM embedded toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads): +```cpp +#include <iostream> +#include <cstdlib> + +int main(int argc, char* argv[]) { + char* env = std::getenv("TEST"); + if (env) + std::cout << "Env TEST: " << env << "\n"; + else + std::cout << "Env TEST not set.\n"; + return 0; +} +``` + +``` +$ $CXX --version +arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release) +Copyright (C) 2020 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +$ $CXX main.cpp --specs=rdimon.specs -mcpu=cortex-m7 +``` + +2. Run in user-space (semihosted): +``` +$ qemu-arm -cpu cortex-m7 -E TEST=val123 ./a.out +Env TEST not set. +``` diff --git a/results/classifier/gemma3:12b/debug/730 b/results/classifier/gemma3:12b/debug/730 new file mode 100644 index 000000000..6435fe51a --- /dev/null +++ b/results/classifier/gemma3:12b/debug/730 @@ -0,0 +1,2 @@ + +test-thread-breakpoint fails with some gdb version diff --git a/results/classifier/gemma3:12b/debug/741115 b/results/classifier/gemma3:12b/debug/741115 new file mode 100644 index 000000000..d683b89aa --- /dev/null +++ b/results/classifier/gemma3:12b/debug/741115 @@ -0,0 +1,9 @@ + +Add support of coprocessor cp15, cp14 registers exposion in the embedded gdb server + +Please add support of exposion of ARM coprocesor registers/logic at the embedded gdb server, + for example of cp15, cp14, etc registers. + +Related project http://jtagarmgdbsrvr.sourceforge.net/index.html + +Also filled bug in the GDB http://sourceware.org/bugzilla/show_bug.cgi?id=12602 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/754635 b/results/classifier/gemma3:12b/debug/754635 new file mode 100644 index 000000000..eb92dbe93 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/754635 @@ -0,0 +1,56 @@ + +-d option outs wrong info about sections + +For example, after run ./qemu-i386 -d in_asm /bin/ls from 0.14.0 release, I received this qemu.log file: +$ cat /tmp/qemu.log | grep -A7 guest +Relocating guest address space from 0x08048000 to 0x8048000 +guest_base 0x0 +start end size prot +00048000-0005f000 00017000 r-x +0005f000-00069000 0000a000 rw- +00040000-00041000 00001000 --- +00041000-00041800 00000800 rw- +00041800-0005d800 0001c000 r-x +0005d800-0005f800 00002000 rw- + +But such command in 0.12.5 release outs this: +$ cat /tmp/qemu.log | grep -A7 guest +guest_base 0x0 +start end size prot +00f38000-00f39000 00001000 --- +08048000-0805f000 00017000 r-x +0805f000-08061000 00002000 rw- +40000000-40080000 00080000 rw- +40080000-40081000 00001000 --- +40081000-4009d000 0001c000 r-x + +It looks correct. +I received such differences and with qemu-microblaze. + +After comparing 0.12.5 and 0.14.0 releases I found this differences in exec.c: +in 0.12.5: +end = (i << (32 - L1_BITS)) | (j << TARGET_PAGE_BITS); + +in 0.14.0: +int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT, + +V_L1_SHIFT in my case is 10, but 32 - L1_BITS is 22 + +I make this changes: +$ diff -up qemu-0.14.0/exec.c exec.c +--- qemu-0.14.0/exec.c 2011-04-08 17:26:00.524464002 +0400 ++++ exec.c 2011-04-08 17:26:09.800464003 +0400 +@@ -2340,7 +2340,7 @@ int walk_memory_regions(void *priv, walk + data.prot = 0; + + for (i = 0; i < V_L1_SIZE; i++) { +- int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT, ++ int rc = walk_memory_regions_1(&data, (abi_ulong)i << (V_L1_SHIFT + TARGET_PAGE_BITS), + V_L1_SHIFT / L2_BITS - 1, l1_map + i); + if (rc != 0) { + return rc; + +After this outputs looks correct. + +I don't know code base good, and think what may to do more general corrections. +Host system: linux i386 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/757702 b/results/classifier/gemma3:12b/debug/757702 new file mode 100644 index 000000000..fd92daf85 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/757702 @@ -0,0 +1,4 @@ + +ARM: singlestepping insn which UNDEFs should stop at UNDEF vector insn, not after it + +ARMv7a has lot of undefined instruction from its instruction opcode space. This undefined instructions are very useful for replacing sensitive non-priviledged instructions of guest operating systems (virtualization). The undefined instruction exception executes at <exception_base> + 0x4, where <exception_base> can be 0x0 or 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, seems like this is a new bug. As as example, if we try to execute value "0xec019800" in qemu 0.14.0 then it should cause undefined exception at <exception_base>+0x4 since "0xec019800" is an undefined instruction. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/837 b/results/classifier/gemma3:12b/debug/837 new file mode 100644 index 000000000..de4ceacba --- /dev/null +++ b/results/classifier/gemma3:12b/debug/837 @@ -0,0 +1,31 @@ + +x86 user: icebp/int1 raises wrong signal +Description of problem: +This is a relatively minor inaccuracy. When `icebp` (`F1`) is executed, it raises `SIGILL` in QEMU, where the behavior on baremetal Linux (on an old Intel Core i5-430m) is to raise `SIGTRAP`. + +Specifically, on the architectural level, `icebp` raises `#DB` without affecting `dr6`. + +This also happens on an AArch64 host. +``` +$ ./icebp +Trace/breakpoint trap +$ qemu-x86_64 ./icebp +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +``` +Steps to reproduce: +1. Compile this file using `gcc -nostdlib -static icebp.S -o icebp`, optionally with `-m32` to test i386 +``` + .globl _start +_start: + .byte 0xF1 // gas doesn't assemble this instruction opcode but it disassembles it +#ifdef __x86_64__ + mov $60, %eax + syscall +#else + mov $1, %eax + int $0x80 +#endif +``` +2. Run on baremetal. Notice how it raises `SIGTRAP` according to the shell job control message +3. Run on qemu-user. Notice how it raises `SIGILL`. diff --git a/results/classifier/gemma3:12b/debug/85 b/results/classifier/gemma3:12b/debug/85 new file mode 100644 index 000000000..72463c248 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/85 @@ -0,0 +1,2 @@ + +info registers' command leads to segfault with -M none diff --git a/results/classifier/gemma3:12b/debug/891002 b/results/classifier/gemma3:12b/debug/891002 new file mode 100644 index 000000000..386780572 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/891002 @@ -0,0 +1,5 @@ + +windows mingw compiled qemu-system-x86_64 crash on startup + +qemu-1.0-rc2/cpu-exec.c:37 longjmp(env->jmp_env, 1); it seems that env->jmp_env destroyed, (gdb) p env->jmp_env +$3 = {0, 0, 0, 36249608, 41418280, 5303318, 41418664, 0, 0, 0, 0, 0, 0, 0, 0, 0} \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/904 b/results/classifier/gemma3:12b/debug/904 new file mode 100644 index 000000000..11eb9eff2 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/904 @@ -0,0 +1,17 @@ + +RISC-V: Cannot set SEIP bit of mip csr register in M mode +Description of problem: + +Steps to reproduce: +1. run assembly instructions **in M mode**: +``` +not t0, x0 // set t0 to 0b11..11 +csrs mip, t0 // write mip with t0, mip registers are WARL(Write Any Values, Reads Legal Values) +csrr t1, mip // read value from mip to t1 +``` +2. GDB enters the command `display/z $t1` to see that the content of the t1 register is 0x466, which means that the SEIP bit of mip is not set. +3. According to page 47 of [riscv-privileged-20211203](https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf), `SEIP is writable in mip`. +4. According to page 81 of the same manual,`If implemented, SEIP is read-only in sip`. +5. However, the above code and results show that the SEIP bit of mip cannot be set by software **in M mode**. +Additional information: + diff --git a/results/classifier/gemma3:12b/debug/911 b/results/classifier/gemma3:12b/debug/911 new file mode 100644 index 000000000..4abbf928c --- /dev/null +++ b/results/classifier/gemma3:12b/debug/911 @@ -0,0 +1,18 @@ + +Unable to strace execve calls in mipsel user mode +Description of problem: +Used 6.2.0 ZIP and git to build, configured with +``` +./configure --target-list=mipsel-linux-user --static --disable-system --enable-linux-user +``` + +When trying to strace a mipsel-arch application, I cannot see traces for the `execve` syscall. It looks like the call to `safe_execve` is not returning, so the strace printout is never completed. I'm assuming this has to do with `execve` syscall not returning on success, but older versions appeared to be able to do it. I tried it with QEMU 4.2.1 from the package manager on Ubuntu and I saw the `execve` syscall (see qemu-4.2.1.log). +Steps to reproduce: +1. Build mipsel app: ` mipsel-linux-gnu-gcc -o test.mipsel test.c` (Test code is attached as `test.c`) +2. Run qemu-mipsel: `./build/qemu-mipsel -L /usr/mipsel-linux-gnu/ -strace ../test.mipsel` +3. Note that even though the app uses both `system` and `popen` to create subprocesses, no `execve` syscall is shown in the strace output. +Additional information: +[qemu-6.2.90.log](/uploads/ca03e6f40b3b0ea79a042786a123760a/qemu-6.2.90.log) +[qemu-6.2.0.log](/uploads/ca15057398377d49b396e9e77a5cb639/qemu-6.2.0.log) +[qemu-4.2.1.log](/uploads/1087250dd9fc4d8d106d2cbc58c2b14a/qemu-4.2.1.log) +[test.c](/uploads/9d242a724b10b296cfd7a945ae4d6c4d/test.c) diff --git a/results/classifier/gemma3:12b/debug/939995 b/results/classifier/gemma3:12b/debug/939995 new file mode 100644 index 000000000..6921587df --- /dev/null +++ b/results/classifier/gemma3:12b/debug/939995 @@ -0,0 +1,34 @@ + +v1.0-1172-g235fe3b crashes (opts=0x0) + +C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios +GNU gdb (GDB) 7.3 +Copyright (C) 2011 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "mingw32". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe... +done. +(gdb) r +Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios +[New Thread 4724.0x1224] + +Program received signal SIGSEGV, Segmentation fault. +0x004eeda6 in qemu_opt_get (opts=0x0, name=0x68a7c3 "kernel") + at qemu-option.c:545 +545 QemuOpt *opt = qemu_opt_find(opts, name); +(gdb) bt +#0 0x004eeda6 in qemu_opt_get (opts=0x0, name=0x68a7c3 "kernel") + at qemu-option.c:545 +#1 0x004c7166 in qemu_main (argc=3, argv=0x3e5200, envp=0x0) + at C:/msys/home/User/qemu/vl.c:3250 +#2 0x004c906a in SDL_main (argc=3, argv=0x3e5200) + at C:/msys/home/User/qemu/vl.c:102 +#3 0x0061dcf4 in console_main () +#4 0x0061ddb4 in WinMain@16 () +#5 0x006329fb in main () +(gdb) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/debug/952 b/results/classifier/gemma3:12b/debug/952 new file mode 100644 index 000000000..9ff14e469 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/952 @@ -0,0 +1,98 @@ + +qemu: uncaught target signal 5 (Trace/breakpoint trap) +Description of problem: +I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal. + +0xa602 <_start> movs r0, #22 + 0xa604 <_start+2> addw r1, pc, #186 ; 0xba +0xa608 <_start+6> bkpt 0x00ab + +$readelf -h hello + +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0xa603 + Start of program headers: 52 (bytes into file) + Start of section headers: 144128 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 5 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 14 + +And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. + +But it's coredump. + +I found that bkpt instruction is not recognized, the bkpt is in 0x0000a608. + +host： +``` +$qemu-arm -g 12345 hello +``` +service: +``` +$gdb-multiarch hello +(gdb) target remote localhost:12345 +Remote debugging using localhost:12345 +0x0000a602 in _start () +(gdb) ni +0x0000a604 in _start () +(gdb) +0x0000a608 in _start () +(gdb) +0x0000a608 in _start () +``` +Another way to check: +``` +$gdb qemu-arm +(gdb) run hello +(gdb) bt +#0 0x00007ffff79474ba in __GI___sigsuspend (set=set@entry=0x7fffffffd9d8) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26 +#1 0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772 +#2 0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099 +#3 0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175 +#4 0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472 +#5 0x0000555555603cf4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../linux-user/main.c:883 +(gdb) up +#1 0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772 +772 sigsuspend(&act.sa_mask); +(gdb) +#2 0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099 +1099 dump_core_and_abort(sig); +(gdb) +#3 0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175 +1175 handle_pending_signal(cpu_env, sig, &ts->sync_signal); +(gdb) +#4 0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472 +472 process_pending_signals(env); +(gdb) l +467 default: +468 error: +469 EXCP_DUMP(env, "qemu: unhandled CPU exception 0x%x - aborting\n", trapnr); +470 abort(); +471 } +472 process_pending_signals(env); +473 } +474 } +475 +476 void target_cpu_copy_regs(CPUArchState *env, struct target_pt_regs *regs) +(gdb) p cpu_exec(cs) +$2 = 7 +``` +Here process_pending_signals(env) gives SIGTRAP?? + +Here is my binary: +[hello](/uploads/7225e1f1c5a61ace40f90d5d2401a758/hello) diff --git a/results/classifier/gemma3:12b/debug/957 b/results/classifier/gemma3:12b/debug/957 new file mode 100644 index 000000000..7b66d3e2b --- /dev/null +++ b/results/classifier/gemma3:12b/debug/957 @@ -0,0 +1,72 @@ + +qemu-m68k: python runtime failures, "The futex facility returned an unexpected error code." +Description of problem: +The python interpreter (both Python 3.9 and Python 3.10) crashes during a rebuild of Python itself (fairly reproducible but not always at the same point of the build; using MAKEOPTS=-j1 or running under high system load decreases the probability, as does using the qemu -systrace switch). The output is +``` +The futex facility returned an unexpected error code. +``` + +Digging into glibc sources, this error together with an abort occurs when the return value of a futex call is not in a short list of allowed values, see ``nptl/futex-internal.c`` and ``sysdeps/nptl/futex-internal.h``. + +Running qemu with QEMU_STRACE=1 decreases the probability of the error greatly, but after some attempts I was able to get a log. Several threads seem to write at the same time, leading to rather garbled output, but my interpretation is an error value of "Invalid argument". + + +``` +116876 get_thread_area(0x00000001) = 989882672 +116876 116876 get_thread_area(0x00000001)get_thread_area(0x00000018) = 989882672 + = 1065219744 +116876 get_thread_area(0x00000000) = 1065219744 +116876 futex(0x3f5003fa,FUTEX_PRIVATE_FLAG|FUTEX_WAIT116876 ,2,116876 NULL,0x3fffda10,get_thread_area(0xffffffff) = 1065219744 +futex(0x3f5003fa,1073732112)FUTEX_PRIVATE_FLAG|FUTEX_WAIT = ,2,NULL,-1 errno=22 (Invalid argument)116876 get_thread_area(0x00000000) + = 1065219744 +0x3fffda10,116876 get_thread_area(0x00000000)1073732112 = )1065219744 +116876 futex(0x3f7d4c34,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL, = 0)-1 errno=22 (Invalid argument) + = 0 + = 116876 get_thread_area(0x3f7d4c34)1 = +116876 get_thread_area(0x00000000) = 1065219744 +926968112 +116876 get_thread_area(0x00000016) = 926968112 +116876 get_thread_area(0x00000000) = 1065219744 +116876 get_thread_area(0x00000000) = 1065219744 +116876 get_thread_area(0x00000001)116876 = futex(116876 0x3f5003fa,get_thread_area(0x00000000)FUTEX_PRIVATE_FLAG| = 926968112 +116876 get_thread_area(0x00000000) = 926968112FUTEX_WAKE +,1,116876 NULL,0x3fffda10,get_thread_area(0x00000000) = 926968112 +1065219744 +116876 get_thread_area(0x00000001)116876 = 1065219744 +1073732112) = 116876 -1 errno=22 (Invalid argument) +futex(0x3ba005fc,FUTEX_PRIVATE_FLAG|FUTEX_CLOCK_REALTIME|FUTEX_WAIT_BITSET,0,NULL,NULL,get_thread_area(0x00000000)0 = 926968112) +116876 get_thread_area(0x00000000) = 926968112 +116876 futex(0x3f7d4c38,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,0x40007bf8,1073773560) = 0 +116876 futex(0x40053a8c,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1 + = 0 +116876 get_thread_area(0x40053a8c) = 885025072 +116876 get_thread_area(0x00000001) = 885025072 +116876 get_thread_area(0x00b4b456) = 885025072 +116876 get_thread_area(0x00000000) = 885025072 +116876 get_thread_area(0x00000000) = 885025072 +116876 Unknown syscall 403 +116876 get_thread_area(0x00000000) = 885025072 +116876 get_thread_area(0x00003baa) = 885025072 +116876 get_thread_area(0x00003b01) = 885025072 +116876 get_thread_area(0x00003b01) = 885025072 +116876 116876 futex(get_thread_area(0x00b4b456)0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAIT_BITSET,0,0x34bfe62c,NULL,0) = 926968112 +116876 get_thread_area(0x00000018) = 926968112 +116876 get_thread_area(0x3ed5b9c8) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 futex(0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000001) = 926968112 +116876 get_thread_area(0x0000000f) = 926968112116876 = 0 + +116876 get_thread_area(0x00000001) = 926968112 +116876 get_thread_area(0x00000001) = 926968112 +116876 get_thread_area(0x00000001)writev(2,0x3affed88,0x1) = 926968112 +The futex facility returned an unexpected error code. +116876 get_thread_area(0x3f7d4c30) = 885025072 +``` + +Advice on how to do further debuggging is appreciated. diff --git a/results/classifier/gemma3:12b/debug/970 b/results/classifier/gemma3:12b/debug/970 new file mode 100644 index 000000000..f0c9ae355 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/970 @@ -0,0 +1,34 @@ + +ARM SCTLR allows writes to "write ignore" bits +Description of problem: +The firmware I have executed in qemu sets up pagetables and then enables the MMU. +A few instructions later, a prefetch abort was occurring. After debugging it turned out the problem was because get_phys_addr_v5 was being used to walk the pagetable instead of get_phys_addr_v6. +qemu has this code: +```c +regime_sctlr(env, mmu_idx) & SCTLR_XP +// where SCTLR_XP is commented as +#define SCTLR_XP (1U << 23) /* up to v6; v7 onward RAO */ +``` +Somewhat interestingly, A5 has a lot of bits marked as `/WI`: https://developer.arm.com/documentation/ddi0433/c/system-control/register-descriptions/system-control-register + +A9 has less, but still a few which qemu is not handling: https://developer.arm.com/documentation/ddi0388/e/the-system-control-coprocessors/summary-of-system-control-coprocessor-registers/system-control-register +I've made this hacky patch to fix it for myself: +```diff +diff --git a/qemu/target/arm/helper.c b/qemu/target/arm/helper.c +index 60c9db9e..d8fd5a7d 100644 +--- a/qemu/target/arm/helper.c ++++ b/qemu/target/arm/helper.c +@@ -4306,6 +4306,11 @@ static void sctlr_write(CPUARMState *env, const ARMCPRegInfo *ri, + { + ARMCPU *cpu = env_archcpu(env); + ++ // for cortex-a5 specifically ++ value |= (0b11 << 22) | (1 << 18) | (1 << 16) | (0b1111 << 3); ++ value &= ~((1 << 31) | (0b11 << 26) | (1 << 24) | (0b111 << 19) | ++ (1 << 17) | (0b11 << 14) | (0b111 << 7)); ++ + if (raw_read(env, ri) == value) { + /* Skip the TLB flush if nothing actually changed; Linux likes + * to do a lot of pointless SCTLR writes. +``` +I think the real fix would allow expressing the ones/zeros mask as part of `ARMCPU` per-arch. diff --git a/results/classifier/gemma3:12b/debug/982 b/results/classifier/gemma3:12b/debug/982 new file mode 100644 index 000000000..e06cb2e73 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/982 @@ -0,0 +1,38 @@ + +linux-user: --strace incorrectly decodes writev arguments for 64-bit binaries on 32-bit machine +Description of problem: +With `--strace`, the arguments to `writev` appear to be decoded incorrectly. +The syscall still succeeds and has the expected effects. +Steps to reproduce: +``` +$ cat main.c +#include <sys/uio.h> + +int main(void) { + struct iovec iov; + iov.iov_base = "hello, world!\n"; + iov.iov_len = 14; + return writev(1, &iov, 1); +} + +$ aarch64-unknown-linux-gnu-gcc -static -o aarch64-main main.c + +$ x86_64-pc-linux-gnu-gcc -static -o x86_64-main main.c + +$ i686-pc-linux-gnu-gcc -static -o i686-main main.c + +$ ./i686-main +hello, world! + +$ strace ./i686-main |& grep writev +writev(1, [{iov_base="hello, world!\n", iov_len=14}], 1hello, world! + +$ qemu-i386 --strace ./i686-main |& grep writev +21953 writev(1,0x407ffe54,0x1) = 14 + +$ qemu-x86_64 --strace ./x86_64-main |& grep writev +22218 writev(1,(nil),0x407ffcc0) = 14 + +$ qemu-aarch64 --strace ./aarch64-main |& grep writev +22523 writev(1,(nil),0x407ffcc8) = 14 +``` diff --git a/results/classifier/gemma3:12b/debug/998 b/results/classifier/gemma3:12b/debug/998 new file mode 100644 index 000000000..a645d39f4 --- /dev/null +++ b/results/classifier/gemma3:12b/debug/998 @@ -0,0 +1,61 @@ + +AArch64: SCTLR_EL1.BT0 set incorrectly in user mode +Description of problem: +PACIASP normally acts as a BTI landing pad, but not in every situation. When SCTLR_EL1.BT is set, PACIASP checks that the indirect branch originates from X16 or X17 when the indirect branch is taken from a BTI guarded area. Linux sets this bit, ideally QEMU-user should too. This sample program should crash with a SIGILL if QEMU is working correctly, otherwise it will crash with a SIGSEGV. + + #include <stdint.h> + #include <stdlib.h> + #include <unistd.h> + #include <string.h> + #include <stdio.h> + #include <sys/mman.h> + + // PACIASP is a valid BTI landing pad, but there are some conditions + // under Linux which sets SCTLR_ELx.BT0 = 1. In this mode, a branch + // onto a PACIASP landing pad is only valid if it originates from + // x16 or x17 (i.e. br x17 is OK, br x3 is not). + // More info on page D5-4851 of the Arm Architecture Reference Manual (ARM DDI 0487H.a). + + // Sample function which starts with a paciasp instruction + // (comes from -mbranch-protection=pac-ret+leaf) + void indirect_fn(int i) { + // paciasp instruction inserted here - should crash with SIGILL here if everything's operating OK. + i = i+1; + // Can't access this function from the copied location, so will segfault. + fprintf(stderr, "reachable\n"); + } + + int main(int argc, char **argv) { + // It's difficult to get a whole binary BTI compatible without the appropriate crtbegin etc + // so instead map a page and copy the sample function there. + void *e = mmap(0, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + if (e == MAP_FAILED) { + return 1; + } + memcpy(e, (void*)indirect_fn, 64); + mprotect(e, getpagesize(), PROT_READ | PROT_EXEC | PROT_BTI); + + // paciasp is a valid landing pad if the branch comes from an unprotected area, + // so to ensure that we're protected - assemble an intermediate shim that's also PROT_BTI. + void *f = mmap(0, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + if (f == MAP_FAILED) { + return 1; + } + uint32_t *x = (uint32_t*)f; + x[0] = 0xd503245fuL; // bti c + x[1] = 0xd61f0060uL; // br x1 - n.b. must be BR + mprotect(f, getpagesize(), PROT_READ | PROT_EXEC | PROT_BTI); + + // Jump to the shim + asm volatile ( + "mov x3, %0\n" + "mov x2, %1\n" + "blr x2\n" + : : "p"(e), "p"(f) : "x2", "x3"); + + // Execution should not reach here + return 1; + } +Steps to reproduce: +1. Compile with `clang-12 -g --sysroot=/work/home/fedora-rootfs/fedora_aarch64 -o sample --target=aarch64-linux-gnu -mbranch-protection=pac-ret+leaf -march=armv8-a -O1 -g sample.c` or similar. +2. Run with `../qemu/build/qemu-aarch64 --cpu max -L ~/fedora-rootfs/fedora_aarch64 sample` |