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

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

[-- Attachment #1: Type: text/plain, Size: 2427 bytes --]

What about my bug report? Up to now I got no replies.

Please include the patch in CVS HEAD - or tell me why you won't do so.

Kind regards
Stefan

Stefan Weil schrieb:
> 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
>> and 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

[-- Attachment #2: cpu-exec.patch --]
[-- Type: text/x-diff, Size: 652 bytes --]

Index: cpu-exec.c
===================================================================
RCS file: /sources/qemu/qemu/cpu-exec.c,v
retrieving revision 1.126
diff -u -r1.126 cpu-exec.c
--- cpu-exec.c	23 Nov 2007 02:11:10 -0000	1.126
+++ cpu-exec.c	30 Nov 2007 22:43:22 -0000
@@ -140,7 +140,11 @@
     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);