Re: [Qemu-devel] [Bug] Fatal error caused by wrong memory access

[Stefan Weil <weil@mail.berlios.de>]

Are there no comments?
What is needed to get this fixed in QEMU CVS?
Do you need additional information?

Stefan

Here is a quick hack patch for this problem:

Index: cpu-exec.c
===================================================================
RCS file: /sources/qemu/qemu/cpu-exec.c,v
retrieving revision 1.100
diff -u -b -B -r1.100 cpu-exec.c
--- cpu-exec.c  9 Apr 2007 22:45:36 -0000       1.100
+++ cpu-exec.c  18 Apr 2007 20:41:44 -0000
@@ -140,8 +140,12 @@
     virt_page2 = (pc + tb->size - 1) & TARGET_PAGE_MASK;
     phys_page2 = -1;
     if ((pc & TARGET_PAGE_MASK) != virt_page2) {
+      if (tb->size == 0) {
+        printf("Bad code in QEMU %s:%u\n", __FILE__, __LINE__);
+      } else {
         phys_page2 = get_phys_addr_code(env, virt_page2);
     }
+    }
     tb_link_phys(tb, phys_pc, phys_page2);

  found:

Stefan Weil schrieb:
> When the program counter is at the very start of a memory block
> amd there is no page allocated before this block, QEMU may fail
> with a fatal error ("Trying to execute code outside RAM or ROM").
>
> In my case, a MIPS system had code in flash starting at 0xb0000000.
> I had a remote debugger attached to the emulated MIPS system and
> set a breakpoint at 0xb0000000. When the breakpoint is reached,
> QEMU terminates while accessing 0xaffff000 (start of page before
> the breakpoint). No crash occurs when the breakpoint is set at
> 0xb0000004 or higher addresses or without a breakpoint.
>
> A first workaround was to allocate a special page for the debugger
> at 0xaffff000. Then I examined the problem and saw that it was not
> caused by the debugger but by QEMU. This code at cpu-exec.c:138
> triggers the fatal error:
>
> /* check next page if needed */
> virt_page2 = (pc + tb->size - 1) & TARGET_PAGE_MASK;
> phys_page2 = -1;
> if ((pc & TARGET_PAGE_MASK) != virt_page2) {
> phys_page2 = get_phys_addr_code(env, virt_page2);
> }
> tb_link_phys(tb, phys_pc, phys_page2);
>
> In my case, tb->size == 0, so virt_page2 is an invalid page just
> before the first valid page. This triggers the fatal error in
> get_phys_addr_code. This might occur for any architecture.
>
> A quick hack could check for tb->size == 0, but maybe there is a
> better solution...
>
> Stefan