From d0af66c2d76056b173294fc81cdfc47305e4e2a7 Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Fri, 6 Jun 2025 09:15:28 +0000 Subject: add new results --- results/classifier/111/debug/1050694 | 113 + results/classifier/111/debug/1084148 | 85 + results/classifier/111/debug/1250360 | 129 ++ results/classifier/111/debug/1305400 | 133 ++ results/classifier/111/debug/1479717 | 72 + results/classifier/111/debug/1580459 | 3972 +++++++++++++++++++++++++++++++++ results/classifier/111/debug/1661386 | 1652 ++++++++++++++ results/classifier/111/debug/1699867 | 58 + results/classifier/111/debug/1708077 | 37 + results/classifier/111/debug/1736042 | 69 + results/classifier/111/debug/1761535 | 84 + results/classifier/111/debug/1835793 | 50 + results/classifier/111/debug/1844635 | 172 ++ results/classifier/111/debug/1876373 | 105 + results/classifier/111/debug/1879587 | 129 ++ results/classifier/111/debug/1880287 | 56 + results/classifier/111/debug/1880822 | 301 +++ results/classifier/111/debug/1897481 | 2105 +++++++++++++++++ results/classifier/111/debug/1923693 | 53 + results/classifier/111/debug/23448582 | 289 +++ results/classifier/111/debug/700276 | 65 + 21 files changed, 9729 insertions(+) create mode 100644 results/classifier/111/debug/1050694 create mode 100644 results/classifier/111/debug/1084148 create mode 100644 results/classifier/111/debug/1250360 create mode 100644 results/classifier/111/debug/1305400 create mode 100644 results/classifier/111/debug/1479717 create mode 100644 results/classifier/111/debug/1580459 create mode 100644 results/classifier/111/debug/1661386 create mode 100644 results/classifier/111/debug/1699867 create mode 100644 results/classifier/111/debug/1708077 create mode 100644 results/classifier/111/debug/1736042 create mode 100644 results/classifier/111/debug/1761535 create mode 100644 results/classifier/111/debug/1835793 create mode 100644 results/classifier/111/debug/1844635 create mode 100644 results/classifier/111/debug/1876373 create mode 100644 results/classifier/111/debug/1879587 create mode 100644 results/classifier/111/debug/1880287 create mode 100644 results/classifier/111/debug/1880822 create mode 100644 results/classifier/111/debug/1897481 create mode 100644 results/classifier/111/debug/1923693 create mode 100644 results/classifier/111/debug/23448582 create mode 100644 results/classifier/111/debug/700276 (limited to 'results/classifier/111/debug') diff --git a/results/classifier/111/debug/1050694 b/results/classifier/111/debug/1050694 new file mode 100644 index 000000000..63d4ee7a7 --- /dev/null +++ b/results/classifier/111/debug/1050694 @@ -0,0 +1,113 @@ +debug: 0.085 +PID: 0.080 +device: 0.078 +other: 0.076 +semantic: 0.076 +permissions: 0.076 +performance: 0.075 +graphic: 0.074 +vnc: 0.069 +files: 0.068 +boot: 0.068 +socket: 0.067 +KVM: 0.056 +network: 0.053 +debug: 0.665 +semantic: 0.055 +other: 0.051 +performance: 0.048 +files: 0.036 +device: 0.034 +socket: 0.024 +PID: 0.017 +network: 0.015 +boot: 0.012 +KVM: 0.011 +permissions: 0.011 +graphic: 0.011 +vnc: 0.010 + +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. + + + +Original conversation about this issue on osdev.org: http://forum.osdev.org/viewtopic.php?f=1&t=25795 + +Triaging old bug tickets ... is there still something left to do here, or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/111/debug/1084148 b/results/classifier/111/debug/1084148 new file mode 100644 index 000000000..1241b8408 --- /dev/null +++ b/results/classifier/111/debug/1084148 @@ -0,0 +1,85 @@ +debug: 0.144 +permissions: 0.115 +semantic: 0.101 +other: 0.086 +graphic: 0.070 +device: 0.068 +files: 0.066 +performance: 0.066 +socket: 0.065 +PID: 0.056 +KVM: 0.045 +network: 0.042 +boot: 0.039 +vnc: 0.038 +debug: 0.667 +performance: 0.057 +files: 0.050 +PID: 0.049 +other: 0.039 +network: 0.023 +graphic: 0.020 +device: 0.018 +semantic: 0.016 +socket: 0.015 +boot: 0.015 +vnc: 0.011 +permissions: 0.011 +KVM: 0.008 + +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 + +It looks as if we've managed to corrupt the translation block graph; at any rate the crash is because we've leapt off into an invalid address. Turning on qemu debug tracing indicates that we're not crashing at the same place every time. This guest binary is multithreaded. Using the patch at http://repo.or.cz/w/qemu/agraf.git/commit/3a3e5eceb1f46808aff5b9d301b708834525c391 is not sufficient to fix this. + +My best guess is that this is just another of the large set of example multithreaded programs which qemu user-mode can't handle. (see also bug 668799). If we care about that we need to put in more resource than the approximately-zero we're currently giving qemu-user-mode. + + +example code which can reproduce the issue is a simple Qt application which tries to run 'ls' command. +http://bazaar.launchpad.net/~juhapekka-piiroinen/+junk/qemu-crash/view/head:/main.cpp + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +Closing this ticket now since there hasn't been any response within the last months + diff --git a/results/classifier/111/debug/1250360 b/results/classifier/111/debug/1250360 new file mode 100644 index 000000000..0f7a1dbfe --- /dev/null +++ b/results/classifier/111/debug/1250360 @@ -0,0 +1,129 @@ +debug: 0.108 +permissions: 0.099 +other: 0.083 +PID: 0.080 +semantic: 0.079 +device: 0.077 +graphic: 0.076 +boot: 0.076 +performance: 0.058 +socket: 0.058 +KVM: 0.056 +files: 0.054 +network: 0.048 +vnc: 0.048 +debug: 0.192 +KVM: 0.146 +files: 0.114 +other: 0.090 +semantic: 0.081 +device: 0.076 +PID: 0.072 +network: 0.049 +socket: 0.040 +performance: 0.034 +permissions: 0.034 +boot: 0.030 +graphic: 0.023 +vnc: 0.019 + +qcow2 image logical corruption after host crash + +Description of problem: +In case of power failure disk images that were active and created in qcow2 format can become logically corrupt so that they actually appear as unused (full of zeroes). +Data seems to be there, but at this moment i cannot find any reliable method to recover it. Should it be a raw image, a recovery path would be available, but a qcow2 image only presents zeroes once it gets corrupted. My understanding is that the blockmap of the image gets reset and the image is then assumed to be unused. +My detailed setup : + +Kernel 2.6.32-358.18.1.el6.x86_64 +qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.7.x86_64 +Used via libvirt libvirt-0.10.2-18.el6_4.14.x86_64 +The image was used from a NFS share (the nfs server did NOT crash and remained permanently active). + +qemu-img check finds no corruption; +qemu-img convert will fully convert the image to raw at a raw image full of zeroes. However, there is data in the file, and the storage backend was not restarted, inactivated during the incident. +I encountered this issue on two different machines, in both cases i was not able to recover the data. +Image was qcow2, thin provisioned, created like this : + qemu-img create -f qcow2 -o cluster_size=2M imagename.img + +While addressing the root cause in order to not have this issue repeat would be the ideal scenario, a temporary workaround to run on the affected qcow2 image to "patch" it and recover the data (eventually after a full fsck/recovery inside the guest) would also be good. Otherwise we are basically losing data on a large scale when using qcow2. + + + +Version-Release number of selected component (if applicable): +Kernel 2.6.32-358.18.1.el6.x86_64 +qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.7.x86_64 +Used via libvirt libvirt-0.10.2-18.el6_4.14.x86_64 + +How reproducible: +I am not able (and don't have at the moment enough resources to try to manually reproduce it), but the probability of the issue seems quite high as this is the second case of such corruption in weeks. +Additional info: +I can privately provide an image displaying the corruption. + +The reported problem has actually two aspects : first is the cause that eventually produces this issue. +The second is the fact that once the logical corruption has occured, qemu-img check finds nothing wrong with the image - this is obviously wrong. + +On Tue, Nov 12, 2013 at 09:17:34AM -0000, Blue wrote: + +Please post the qemu command-line (ps aux | grep qemu) for the affected +VM. + +What kind of workload is accessing the disk? Guest OS and version? + +Please also confirm that nothing else is accessing the image file while +the VM is running. It is not safe to use tools like qemu-img on the +file while the VM has it open. + +> Image was qcow2, thin provisioned, created like this : +> qemu-img create -f qcow2 -o cluster_size=2M imagename.img + +Interesting note, you are setting a custom cluster size. It should work +but it's not the default configuration that is well-tested. + +> I can privately provide an image displaying the corruption. + +Please send a link to