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

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

[Stefan Weil]

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

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

[Stefan Weil]

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

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

[Stefan Weil]

[-- 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);
 

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

[andrzej zaborowski]

On 30/11/2007, Stefan Weil <weil@mail.berlios.de> wrote:
> 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.

Please check that you can still reproduce the error. pbrook explains
that tb->size cannot be zero unless there's a bug elsewhere, and there
was such a bug on MIPS but only until r97 of target-mips/translate.c.

Regards

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

[Stefan Weil]

andrzej zaborowski schrieb:
> On 30/11/2007, Stefan Weil <weil@mail.berlios.de> wrote:
>   
>> 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.
>>     
>
> Please check that you can still reproduce the error. pbrook explains
> that tb->size cannot be zero unless there's a bug elsewhere, and there
> was such a bug on MIPS but only until r97 of target-mips/translate.c.
>
> Regards
Thank you for your answer. I checked with current HEAD (1) and
with HEAD + reversed patch from r96-r97 (2). Only (2) is buggy,
so it was this bug on MIPS which was fixed five months after my
first bug report.

Regards
Stefan