All of
 help / color / mirror / Atom feed
From: Simon Tatham <>
Subject: [Bug 1918302] Re: qemu-system-arm segfaults while servicing SYS_HEAPINFO
Date: Thu, 25 Mar 2021 14:48:12 -0000	[thread overview]
Message-ID: <> (raw)

Firstly, I agree with Peter's comment – this test image is exactly an
example of what he describes, in that it carefully doesn't make any use
of the value of SP it started up with (doesn't push or pop anything,
doesn't make sp-relative offsets). Very near the start, it invokes
SYS_HEAPINFO to decide what to set SP to.

I retried the image with qemu master, running qemu-system-arm itself
inside gdb to help figure out what was going on. What seems to happen,
in detail, is:

1. common_semi_find_region_base falls through to the fallback "return 0;" at the end of the function, because the iteration found no subregion at all with subregion->ram set to true. In fact the five regions it iterated through were:
addr = 0x4000a000, size = 0x1000, ram = 0x0, readonly = 0x0
addr = 0x40009000, size = 0x1000, ram = 0x0, readonly = 0x0
addr = 0x40008000, size = 0x1000, ram = 0x0, readonly = 0x0
addr = 0xf0000000, size = 0x10000000, ram = 0x0, readonly = 0x0
addr = 0x40000000, size = 0x20000000, ram = 0x0, readonly = 0x0

2. So common_semi_rambase returns zero to the TARGET_SYS_HEAPINFO
handler in do_common_semihosting().

3. current_machine->ram_size is set to 0x8000000, and with rambase=0, the SYS_HEAPINFO handler ends up computing the following values in retvals[]:
retvals[0] (heap base)   = 0x4000000
retvals[1] (heap limit)  = 0x8000000
retvals[2] (stack base)  = 0x8000000
retvals[3] (stack limit) = 0x0

4. The setup code faithfully initializes sp to 0x8000000, and then crashes on the first PUSH instruction that the program executes:
0x00001950:  b5b0       push     {r4, r5, r7, lr}

5. That's how we end up in the tight loop at 0xce4 as mentioned above:
in this test image, that's the address of the dummy handler for (among
other things) memory faults.

The emulated machine definitely has some RAM at 0x20000000, because
that's where the SYS_HEAPINFO output block was, and the semihosting code
was happy to write to there. So I think SYS_HEAPINFO surely _ought_ to
have returned some heap and stack values in that region. And the reason
it didn't was that for some reason it didn't find any RAM regions at all
in the iteration through get_system_memory()->subregions.

So I think there are still two problems. Using the input value of SP to
decide which RAM region to return is surely the wrong policy, because SP
is literally uninitialised at this point. But also, finding any RAM
regions *at all* seems to be failing in this case.

You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

  qemu-system-arm segfaults while servicing SYS_HEAPINFO

Status in QEMU:
  Fix Committed

Bug description:
  I compiled QEMU version 5.2.0 from source on Ubuntu 18.04, and tried
  to use it to run the attached bare-metal Arm hello-world image, using
  the command line

  qemu-system-arm -M microbit -semihosting -nographic -device

  The result was that qemu-system-arm itself died of a segfault.
  Compiling it for debugging, the location of the segfault was in
  target/arm/arm-semi.c, in the case handler for the semihosting call
  TARGET_SYS_HEAPINFO, on line 1020 which assigns to 'rambase':

              const struct arm_boot_info *info = env->boot_info;
              target_ulong rambase = info->loader_start;

  and the problem seems to be that 'info', aka env->boot_info, is NULL
  in this context.

To manage notifications about this bug go to:

  parent reply	other threads:[~2021-03-25 15:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-09 15:30 [Bug 1918302] [NEW] qemu-system-arm segfaults while servicing SYS_HEAPINFO Simon Tatham
2021-03-11 18:44 ` [Bug 1918302] " Peter Maydell
2021-03-12 15:00 ` Peter Maydell
2021-03-12 15:04 ` Peter Maydell
2021-03-15 10:53 ` Alex Bennée
2021-03-15 12:42 ` Alex Bennée
2021-03-15 12:43 ` Alex Bennée
2021-03-15 12:45 ` Alex Bennée
2021-03-15 13:28 ` Peter Maydell
2021-03-25 11:49 ` Alex Bennée
2021-03-25 13:16 ` Peter Maydell
2021-03-25 14:48 ` Simon Tatham [this message]
2021-03-25 14:49 ` Simon Tatham
2021-03-25 15:31 ` Peter Maydell
2021-03-25 15:49 ` Simon Tatham
2021-04-30  9:16 ` Thomas Huth
2021-04-30 10:13 ` Peter Maydell
2021-05-01  5:42 ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.