summary refs log tree commit diff stats
path: root/results/scraper/launchpad-without-comments/1180970
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-06-30 12:24:58 +0000
committerChristian Krinitsin <mail@krinitsin.com>2025-06-30 12:27:06 +0000
commit33606b41d35115f887ea688b1a16f2ff85bf2fe4 (patch)
tree406b2c7b19a087ba437c68f3dbf0b589fa1d6150 /results/scraper/launchpad-without-comments/1180970
parentadedf8771bc4de3113041ca21bd4d0d1c0014b6a (diff)
downloademulator-bug-study-33606b41d35115f887ea688b1a16f2ff85bf2fe4.tar.gz
emulator-bug-study-33606b41d35115f887ea688b1a16f2ff85bf2fe4.zip
add launchpad bug reports without comments
Diffstat (limited to 'results/scraper/launchpad-without-comments/1180970')
-rw-r--r--results/scraper/launchpad-without-comments/118097038
1 files changed, 38 insertions, 0 deletions
diff --git a/results/scraper/launchpad-without-comments/1180970 b/results/scraper/launchpad-without-comments/1180970
new file mode 100644
index 00000000..aa9ea9d0
--- /dev/null
+++ b/results/scraper/launchpad-without-comments/1180970
@@ -0,0 +1,38 @@
+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