diff options
Diffstat (limited to 'results/classifier/zero-shot/118/PID')
| -rw-r--r-- | results/classifier/zero-shot/118/PID/1426 | 68 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/PID/1705 | 96 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/PID/1721 | 92 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/PID/1760 | 83 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/PID/1821054 | 83 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/PID/1825452 | 76 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/PID/2423 | 64 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/PID/303 | 31 | ||||
| -rw-r--r-- | results/classifier/zero-shot/118/PID/655 | 62 |
9 files changed, 655 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/PID/1426 b/results/classifier/zero-shot/118/PID/1426 new file mode 100644 index 000000000..37b4174ab --- /dev/null +++ b/results/classifier/zero-shot/118/PID/1426 @@ -0,0 +1,68 @@ +PID: 0.864 +device: 0.832 +socket: 0.829 +register: 0.828 +ppc: 0.756 +arm: 0.725 +risc-v: 0.724 +VMM: 0.716 +files: 0.699 +mistranslation: 0.689 +performance: 0.672 +vnc: 0.671 +graphic: 0.668 +network: 0.648 +boot: 0.643 +architecture: 0.626 +hypervisor: 0.616 +semantic: 0.609 +user-level: 0.602 +KVM: 0.552 +permissions: 0.533 +x86: 0.525 +debug: 0.480 +TCG: 0.432 +peripherals: 0.413 +kernel: 0.374 +virtual: 0.334 +i386: 0.321 +assembly: 0.256 + +On windows, display spice-app is not able to initialize, start spice-server and consequently can't use spice-client +Description of problem: +I want to try windows spice-client / virt-viewer.exe (v11.0.256) instead of gtk client. +Windows spice client virtviewer won't start like it does under Linux. +The error message indicaes that the spice-server itself failed to open spice sockets +The registry to handle ```spice://``` URI handler is configured. +Steps to reproduce: +1. just run command +Additional information: +URI handler in registry is configure using a regestry import file ```spiceproto.reg``` +``` +Windows Registry Editor Version 5.00 + +[HKEY_CLASSES_ROOT\spice] +"URL Protocol"="" + +[HKEY_CLASSES_ROOT\spice\DefaultIcon] +@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1" + +[HKEY_CLASSES_ROOT\spice\Extensions] +[HKEY_CLASSES_ROOT\spice\shell] +[HKEY_CLASSES_ROOT\spice\shell\open] +[HKEY_CLASSES_ROOT\spice\shell\open\command] +@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\"" + +[HKEY_CLASSES_ROOT\spice+unix] +"URL Protocol"="" + +[HKEY_CLASSES_ROOT\spice+unix\DefaultIcon] +@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1" + +[HKEY_CLASSES_ROOT\spice+unix\Extensions] +[HKEY_CLASSES_ROOT\spice+unix\shell] +[HKEY_CLASSES_ROOT\spice+unix\shell\open] +[HKEY_CLASSES_ROOT\spice+unix\shell\open\command] +@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\"" +``` +This URI handler is working, and can be seen to work by typing ```spice://abcdefg``` in firefox. diff --git a/results/classifier/zero-shot/118/PID/1705 b/results/classifier/zero-shot/118/PID/1705 new file mode 100644 index 000000000..cd35fa0a0 --- /dev/null +++ b/results/classifier/zero-shot/118/PID/1705 @@ -0,0 +1,96 @@ +PID: 0.865 +user-level: 0.843 +debug: 0.831 +graphic: 0.829 +hypervisor: 0.804 +permissions: 0.803 +vnc: 0.789 +mistranslation: 0.788 +semantic: 0.785 +risc-v: 0.784 +device: 0.781 +performance: 0.778 +x86: 0.770 +peripherals: 0.767 +virtual: 0.766 +architecture: 0.762 +arm: 0.761 +boot: 0.745 +TCG: 0.744 +files: 0.729 +assembly: 0.728 +register: 0.726 +network: 0.725 +kernel: 0.715 +VMM: 0.709 +KVM: 0.699 +ppc: 0.697 +socket: 0.679 +i386: 0.633 + +Illegal instruction when I want to numactl --cpubind=0 --membind=1 to CXL Memory +Description of problem: +I ran QEMU for simulating CXL DRAM and when I tried to run `numactl --cpubind=0 --membind=1 ls` , I got `Illegal instruction` +The numa node 1 was the CXL DRAM simulated by QEMU. + +> root@8003:~# numactl -H +> available: 2 nodes (0-1) +> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 +> node 0 size: 32090 MB +> node 0 free: 31325 MB +> node 1 cpus: +> node 1 size: 32768 MB +> node 1 free: 32768 MB +> node distances: +> node 0 1 +> 0: 10 20 +> 1: 20 10 + +When I ran on numa node 1, no failed + +> root@8003:~# numactl --membind=0 ls +> ndctl + +When I ran on numa node 1(CXL DRAM),it failed. + +> root@8003:~# numactl --membind=1 ls +> [ 913.975032] traps: ls[667] trap invalid opcode ip:7fdec255d180 sp:7ffd3c507288 error:0 in ld-linux-x86-64.so.2[7fdec2546000+2a000] +> **Illegal instruction** +Steps to reproduce: +1. start the guest +2. cxl list (we could see the simulated CXL DRAM) +> root@8003:~# cxl list +> [ +> { +> "memdev":"mem0", +> "ram_size":34359738368, +> "serial":0, +> "host":"0000:0d:00.0" +> } +> ] +3. cxl create-region -t ram -d decoder0.0 -m mem0 +4. daxctl reconfigure-device dax0.0 --mode=system-ram +5. numactl -H +> root@8003:~# numactl -H +> available: 2 nodes (0-1) +> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 +> node 0 size: 32090 MB +> node 0 fr +> ee: 31254 MB +> node 1 cpus: +> node 1 size: 32768 MB +> node 1 free: 32768 MB +> node distances: +> node 0 1 +> 0: 10 20 +> 1: 20 10 +6. numactl --membind=1 ls +> root@8003:~# numactl --membind=1 ls +> [38441.892140] **traps: ls[861] trap invalid opcode ip:7f15db6ac180 sp:7ffc648755c8 **error:0 in ld-linux-x86-64.so.2[7f15db695000+2a000] +> **Illegal instruction** +Additional information: +When I run dmesg, I found an error. +> root@8003:~# dmesg|grep error +> [ 2.321130] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 + +Since my CPU is a Xeon III, not a Xeon IV with CXL support, **I'm wondering if it's because the CPU doesn't support CXL instructions, or if the Xeon III can emulate it, just because my settings don't make sense**. If this is my settings problem, could you help me to deal this? Or it just caused by my Xeon III,I will update it to Xeon IV. diff --git a/results/classifier/zero-shot/118/PID/1721 b/results/classifier/zero-shot/118/PID/1721 new file mode 100644 index 000000000..b0bb9d305 --- /dev/null +++ b/results/classifier/zero-shot/118/PID/1721 @@ -0,0 +1,92 @@ +PID: 0.870 +permissions: 0.860 +assembly: 0.858 +graphic: 0.852 +semantic: 0.838 +device: 0.833 +architecture: 0.830 +register: 0.827 +files: 0.826 +socket: 0.826 +arm: 0.824 +KVM: 0.822 +virtual: 0.820 +TCG: 0.819 +VMM: 0.811 +peripherals: 0.811 +user-level: 0.807 +vnc: 0.797 +ppc: 0.793 +debug: 0.788 +kernel: 0.778 +hypervisor: 0.768 +x86: 0.743 +performance: 0.730 +risc-v: 0.721 +boot: 0.720 +i386: 0.672 +network: 0.645 +mistranslation: 0.595 + +Problem in combination with RabbitMQ and erlang +Description of problem: +I have a problem with rabbitMQ /erlang / Qemu on my local system. + +I use docker with: + +version: "3.6" +``` +services: + rabbitmq: + image: rabbitmq:3-management +``` + +Docker Desktop 4.20.1 (110738) +Docker version 24.0.2, build cb74dfc + +Apple Macbook Pro with M1 Chip Ventura 13.4. + +I deleted all containers and images related to rabbitMQ. Then when I do a: docker compose up -d + +I always get this error and rabbitMQ stopps: + +``` +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:18.984151+00:00 [notice] <0.44.0> Application mnesia exited with reason: stopped +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:20.658039+00:00 [info] <0.230.0> Waiting for Mnesia tables for 30000 ms, 9 retries left +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:20.659274+00:00 [info] <0.230.0> Successfully synced tables from a peer +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:20.662647+00:00 [notice] <0.283.0> Feature flags: attempt to enable `stream_sac_coordinator_unblock_group`... +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:20.793670+00:00 [notice] <0.283.0> Feature flags: `stream_sac_coordinator_unblock_group` enabled +rabbitmq-server-rabbitmq-1 | qemu: uncaught target signal 11 (Segmentation fault) - core dumped +rabbitmq-server-rabbitmq-1 | Segmentation fault +``` + +In the past it worked, like 5 months ago. + +Reproduction steps docker compose up -d + +Expected behavior that the container runs and does not exit + +Additional context docker compose logs + +``` +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.946635+00:00 [notice] <0.44.0> Application syslog exited with reason: stopped +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.966134+00:00 [notice] <0.230.0> Logging: switching to configured handler(s); following messages may not be visible in this log output +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:06.973002+00:00 [notice] <0.230.0> Logging: configured log handlers are now ACTIVE +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.539052+00:00 [info] <0.230.0> ra: starting system quorum_queues +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.539748+00:00 [info] <0.230.0> starting Ra system: quorum_queues in directory: /var/lib/rabbitmq/mnesia/rabbit@4fb71bcd203a/quorum/rabbit@4fb71bcd203a +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.715984+00:00 [info] <0.261.0> ra system 'quorum_queues' running pre init for 0 registered servers +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.749375+00:00 [info] <0.262.0> ra: meta data store initialised for system quorum_queues. 0 record(s) recovered +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.786151+00:00 [notice] <0.267.0> WAL: ra_log_wal init, open tbls: ra_log_open_mem_tables, closed tbls: ra_log_closed_mem_tables +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.857344+00:00 [info] <0.230.0> ra: starting system coordination +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.857635+00:00 [info] <0.230.0> starting Ra system: coordination in directory: /var/lib/rabbitmq/mnesia/rabbit@4fb71bcd203a/coordination/rabbit@4fb71bcd203a +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.868808+00:00 [info] <0.274.0> ra system 'coordination' running pre init for 0 registered servers +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.874965+00:00 [info] <0.275.0> ra: meta data store initialised for system coordination. 0 record(s) recovered +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.875747+00:00 [notice] <0.280.0> WAL: ra_coordination_log_wal init, open tbls: ra_coordination_log_open_mem_tables, closed tbls: ra_coordination_log_closed_mem_tables +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Starting RabbitMQ 3.12.0 on Erlang 25.3.2.2 [jit] +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Copyright (c) 2007-2023 VMware, Inc. or its affiliates. +rabbitmq-server-rabbitmq-1 | 2023-06-22 08:12:07.899618+00:00 [info] <0.230.0> Licensed under the MPL 2.0. Website: https://rabbitmq.com +rabbitmq-server-rabbitmq-1 | +rabbitmq-server-rabbitmq-1 | +Additional information: + diff --git a/results/classifier/zero-shot/118/PID/1760 b/results/classifier/zero-shot/118/PID/1760 new file mode 100644 index 000000000..4e4b3050a --- /dev/null +++ b/results/classifier/zero-shot/118/PID/1760 @@ -0,0 +1,83 @@ +i386: 0.991 +PID: 0.966 +kernel: 0.957 +architecture: 0.944 +performance: 0.934 +graphic: 0.920 +device: 0.909 +files: 0.860 +debug: 0.831 +ppc: 0.775 +peripherals: 0.771 +network: 0.727 +permissions: 0.714 +user-level: 0.659 +assembly: 0.651 +arm: 0.622 +VMM: 0.616 +vnc: 0.615 +socket: 0.609 +TCG: 0.596 +boot: 0.551 +KVM: 0.516 +semantic: 0.502 +hypervisor: 0.476 +register: 0.449 +risc-v: 0.445 +mistranslation: 0.426 +x86: 0.321 +virtual: 0.169 + +qemu8-i386 gets wrong arguments for 32-bit old mmap syscall (_NR_mmap = 90) +Description of problem: +qemu8-i386 does not decode syscall arguments correctly for system call _NR_mmap = 90 on i386. +``` +$ strace ./oldmmap +execve("./oldmmap", ["./oldmmap"], 0x7fff46ba6d40 /* 61 vars */) = 0 +[ Process PID=405233 runs in 32 bit mode. ] +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fa7000 +exit(5) = ? ++++ exited with 5 +++ + +$ build/qemu-i386 -strace ./oldmmap +405254 mmap(0x40800058,0,PROT_NONE,0,0,0) = 0x3fffb000 +405254 exit(5) +``` +Steps to reproduce: +1. gcc -m32 -o oldmmap -nostartfiles -nostdlib oldmmap.S # build 32-bit executable +2. strace ./oldmmap # run under strace +3. build/qemu-i386 -strace ./oldmmap # run under "qemu-i386 -strace" +4. Notice that qemu-i386 did not report the same arguments to the _NR_map syscall as /usr/bin/strace did. +Additional information: +``` +$ cat oldmmap.S +MAP_FIXED= 0x10 +MAP_PRIVATE= 0x02 +MAP_ANONYMOUS= 0x20 + +PROT_READ= 1 +PROT_WRITE= 2 +PROT_EXEC= 4 + +_NR_exit = 1 +_NR_mmap = 90 // oldmmap: %ebx -> array of 6 arguments + + .globl _start +_start: + push $0 // offset + push $-1 // fd + push $MAP_PRIVATE|MAP_ANONYMOUS // flags + push $PROT_READ|PROT_WRITE // protection + push $2<<12 // length + push $0 // addr (kernel chooses) + mov %esp,%ebx + mov $_NR_mmap,%eax + int $0x80 + nop + + mov $5,%ebx + mov $_NR_exit,%eax + int $0x80 + hlt +$ +``` diff --git a/results/classifier/zero-shot/118/PID/1821054 b/results/classifier/zero-shot/118/PID/1821054 new file mode 100644 index 000000000..4abcd9d49 --- /dev/null +++ b/results/classifier/zero-shot/118/PID/1821054 @@ -0,0 +1,83 @@ +PID: 0.959 +user-level: 0.958 +semantic: 0.914 +mistranslation: 0.913 +ppc: 0.913 +graphic: 0.909 +architecture: 0.906 +device: 0.904 +performance: 0.894 +peripherals: 0.885 +permissions: 0.885 +TCG: 0.868 +risc-v: 0.867 +i386: 0.858 +debug: 0.844 +assembly: 0.830 +register: 0.825 +x86: 0.818 +vnc: 0.818 +hypervisor: 0.805 +VMM: 0.804 +socket: 0.761 +kernel: 0.750 +KVM: 0.722 +arm: 0.708 +boot: 0.699 +network: 0.697 +files: 0.693 +virtual: 0.620 + +qemu segfault error when using pcie to dual pci adapter + +All the information I have is located in the Unraid forum on post "https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor" +I am happy to provide any addition information requested. Please let me know. Reporting bug here based on recommendation by admin in that forum. + +hmm that's a fun board. + +It looks like qemu has segfaulted; + 1) is this a qemu build you built yourself? If so, exactly which version, built on which distro? + 2) Could you get a backtrace of qemu crashing - this might be easiest if your distro records core dumps somewhere. + +FYI: I was happy to find the board and I'm hopeful to get it working. My goal is to use old hardware to make a retro gaming machine for my girls to play games I used to play growing up. + +1)No its the qemu installed with unraid version 6.6.7, which i believe is qemu 3.0 +2)im willing to get any notes, logs, or dumps you wish. I just need to know how to do it. + +I don't know anything about unraid unfortunately; so I suggest you go back to their forums and ask how to get the backtrace. + +I have requested additional info in the other forum. While I wait on reply there, i will say, since you dont know it well, that Unraid is a disto built on top of slackware. Are there any basic command line commands that i could run to get the output you requested, or something to keep things moving while i wait on additional info from the other forum. + +Hi! Did you ever get a backtrace? ... otherwise I think we have to close this ticket due to insufficient data... + +No I never did. I reached out to try and get info on how to run or get a backtrack and never heard anything. I finally gave up and ended up selling the computer since I never got it working how I wanted to. + +> On Nov 25, 2020, at 10:20 AM, Thomas Huth <email address hidden> wrote: +> +> Hi! Did you ever get a backtrace? ... otherwise I think we have to close +> this ticket due to insufficient data... +> +> ** Changed in: qemu +> Status: New => Incomplete +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1821054 +> +> Title: +> qemu segfault error when using pcie to dual pci adapter +> +> Status in QEMU: +> Incomplete +> +> Bug description: +> All the information I have is located in the Unraid forum on post "https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor" +> I am happy to provide any addition information requested. Please let me know. Reporting bug here based on recommendation by admin in that forum. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1821054/+subscriptions + + +Ok, thanks for getting back. So I'm closing this now due to insufficient data. + diff --git a/results/classifier/zero-shot/118/PID/1825452 b/results/classifier/zero-shot/118/PID/1825452 new file mode 100644 index 000000000..71e26b0aa --- /dev/null +++ b/results/classifier/zero-shot/118/PID/1825452 @@ -0,0 +1,76 @@ +ppc: 0.945 +user-level: 0.931 +PID: 0.921 +permissions: 0.915 +network: 0.865 +files: 0.856 +register: 0.849 +debug: 0.845 +mistranslation: 0.831 +vnc: 0.825 +semantic: 0.816 +device: 0.815 +graphic: 0.809 +architecture: 0.788 +virtual: 0.751 +kernel: 0.738 +peripherals: 0.737 +performance: 0.735 +socket: 0.732 +arm: 0.716 +boot: 0.684 +risc-v: 0.651 +VMM: 0.645 +assembly: 0.636 +TCG: 0.584 +x86: 0.515 +hypervisor: 0.514 +i386: 0.439 +KVM: 0.377 + +Pulse audio backend doesn't work in v4.0.0-rc4 release + +Using Gentoo linux, build from source: qemu v4.0.0-rc4 release (eeba63fc7fface36f438bcbc0d3b02e7dcb59983) + +Pulse audio backend doesn't initialize because of the: +audio/paaudio.c: +- if (!popts->has_server) { +- char pidfile[64]; +- char *runtime; +- struct stat st; +- +- runtime = getenv("XDG_RUNTIME_DIR"); +- if (!runtime) { +- return NULL; +- } +- snprintf(pidfile, sizeof(pidfile), "%s/pulse/pid", runtime); +- if (stat(pidfile, &st) != 0) { +- return NULL; +- } +- } +XDG_RUNTIME_DIR is not set for me. There is no /run/user directory exist in my system. + +Also: +$ less ~/.pulse/client.conf +default-server = unix:/home/ivan/.pulse_server + +Removing this lines makes pa backend work fine again. Much better than 3.x versions due to buffer fixes. + +It looks like this code relies on the systemd specifics and doesn't work with OpenRC used in Gentoo by default. Still not fixed in 4.0.0 release. + +You can use -audiodev pa,id=whatever,server=unix:/home/ivan/.pulse_server to get things going with your configuration. + +Oh, and this has nothing to do with systemd: + +kraxel@gentoo ~ $ set | grep ^XDG +XDG_CONFIG_DIRS=/etc/xdg +XDG_DATA_DIRS=/usr/local/share:/usr/share +XDG_RUNTIME_DIR=/var/run/user/1000 +XDG_SESSION_COOKIE=gentoo-1556780854.41316-799155214 + +(gentoo with openrc + xfce, serial console login, x11 login has a few more of these set). + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/118/PID/2423 b/results/classifier/zero-shot/118/PID/2423 new file mode 100644 index 000000000..58dd1f988 --- /dev/null +++ b/results/classifier/zero-shot/118/PID/2423 @@ -0,0 +1,64 @@ +PID: 0.960 +x86: 0.905 +performance: 0.877 +graphic: 0.868 +device: 0.779 +peripherals: 0.749 +permissions: 0.701 +semantic: 0.674 +debug: 0.645 +user-level: 0.611 +kernel: 0.562 +register: 0.560 +architecture: 0.553 +vnc: 0.508 +ppc: 0.508 +socket: 0.498 +network: 0.492 +boot: 0.448 +risc-v: 0.420 +i386: 0.418 +mistranslation: 0.400 +files: 0.386 +TCG: 0.372 +VMM: 0.362 +arm: 0.324 +KVM: 0.264 +hypervisor: 0.233 +virtual: 0.171 +assembly: 0.145 + +`qemu -serial stdio` leaves stdout in non-blocking mode +Description of problem: +When `-serial stdio` is used, qemu exits leaving stdout in non-blocking mode. Although it [attempts](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L52) to restore stdin to blocking mode, it misses that stdout also gets O_NONBLOCK by [qemu_chr_open_fd](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L116) ([here](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-fd.c#L215)). It causes the next applications in the script misbehave because they get unexpected EAGAIN on write to stdout. +Steps to reproduce: +Run the following script: + +``` +#!/usr/bin/env bash + +qemu-system-x86_64 -nodefaults -display none -no-reboot -serial stdio & +PID="$!" +sleep 5 +kill "$PID" +wait "$PID" +echo "EXITING $?" + +sleep 5 +seq 1 400000 +``` + +The seq command will be interrupted prematurely: + +``` +... +5143 +5144 +5145⏎ wResource temporarily unavailable +write: Resource temporarily unavailable +write: Resource temporarily unavailable +``` + +When run from fish shell, it will also start misbehaving when running next commands (fish bug report: https://github.com/fish-shell/fish-shell/issues/10600). +Additional information: +Expect a patch from me soon. diff --git a/results/classifier/zero-shot/118/PID/303 b/results/classifier/zero-shot/118/PID/303 new file mode 100644 index 000000000..68bb04050 --- /dev/null +++ b/results/classifier/zero-shot/118/PID/303 @@ -0,0 +1,31 @@ +PID: 0.869 +device: 0.847 +performance: 0.623 +mistranslation: 0.507 +architecture: 0.464 +debug: 0.408 +graphic: 0.352 +semantic: 0.350 +x86: 0.270 +boot: 0.268 +i386: 0.239 +arm: 0.212 +register: 0.181 +TCG: 0.180 +ppc: 0.123 +assembly: 0.113 +virtual: 0.103 +VMM: 0.101 +files: 0.098 +peripherals: 0.092 +vnc: 0.089 +network: 0.087 +user-level: 0.084 +socket: 0.079 +risc-v: 0.065 +permissions: 0.051 +kernel: 0.014 +KVM: 0.006 +hypervisor: 0.005 + +assert issue locates in hw/usb/core.c:727: usb_ep_get: Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed diff --git a/results/classifier/zero-shot/118/PID/655 b/results/classifier/zero-shot/118/PID/655 new file mode 100644 index 000000000..51b05e556 --- /dev/null +++ b/results/classifier/zero-shot/118/PID/655 @@ -0,0 +1,62 @@ +PID: 0.989 +kernel: 0.972 +ppc: 0.969 +device: 0.968 +architecture: 0.963 +files: 0.948 +graphic: 0.942 +semantic: 0.936 +permissions: 0.892 +vnc: 0.884 +VMM: 0.878 +TCG: 0.871 +performance: 0.868 +network: 0.853 +socket: 0.852 +register: 0.848 +debug: 0.832 +KVM: 0.828 +risc-v: 0.811 +hypervisor: 0.781 +boot: 0.745 +virtual: 0.738 +user-level: 0.735 +arm: 0.716 +mistranslation: 0.637 +peripherals: 0.629 +x86: 0.343 +assembly: 0.261 +i386: 0.079 + +Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8' +Description of problem: +The `java` command fails with the following message: + +```console +$ /usr/lib/jvm/java-17-openjdk-s390x/bin/java --version +# +# A fatal error has been detected by the Java Runtime Environment: +# +# SIGILL (0x4) at pc=0x000003ff9e4fe6f4, pid=2883, tid=2884 +# +# JRE version: (17.0+35) (build ) +# Java VM: OpenJDK 64-Bit Server VM (17+35-Ubuntu-120.04, mixed +# mode, sharing, tiered, compressed oops, compressed class ptrs, +# serial gc, linux-s390x) +# Problematic frame: +# C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8 +# +# Core dump will be written. Default location: Core dumps may +# be processed with "/usr/share/apport/apport %p %s %c %d %P %E" +# (or dumping to /home/ubuntu/core.2883) +# +# An error report file with more information is saved as: +# /home/ubuntu/hs_err_pid2883.log +# +# +Aborted (core dumped) +``` +Steps to reproduce: +1. Run `java --version` +Additional information: +The corresponding log file is attached as the file [hs_err_pid2883.log](/uploads/1631b6a0f0aad2f77c4928ed6bb540c6/hs_err_pid2883.log). |