qemu-aarch64-static segfaults

The attachment "qemu.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

I'm a little nervous about the do_sigprocmask in linux-user/signal.c for all arches. With the comment

/* Force set state of SIGSEGV, may be best for some apps, maybe not so good
++ * This is not required for qemu to work

Doing this conditionally for arm64 would be more comforting...

I'll go ahead and run some tests with it tomorrow on amd64.

Dann,

can you confirm that you can reproduce this with the upstream git head (or the qemu-2.0~git package)?

I'm building a candidate package with a modified version of the patchset (to only change behavior for aarch64 targets) in ppa:serge-hallyn/virt.

On Thu, Feb 27, 2014 at 3:34 PM, Serge Hallyn
<email address hidden> wrote:
> Dann,
>
> can you confirm that you can reproduce this with the upstream git head
> (or the qemu-2.0~git package)?

I just reverified with upstream git head @
9fbee91a131a05e443d7108d7fbdf3ca91020290.
Note that this appears to only be reproducible on systems with > 1 CPU
(easy to reproduce on 4).

@Serge: I can confirm that this is fixed in 1.7.0+dfsg-3ubuntu5sig1 from your ppa.

Doing this only for aarch64 targets seems like a bad idea to me -- this isn't an aarch64 specific issue. QEMU needs SIGSEGV to go to its own handler (so we can unprotect pages we've marked as read-only in order to catch guest writes to them so we can throw away invalidated translated code), and that's true for all targets. It probably just happens more often on the aarch64 target than others you've tested because aarch64 has a signal-return trampoline on the stack frame, so we'll often see that page get translated and thrown away again. (Other targets with a trampoline include sparc, cris, openrisc and ppc.)

PS: the comment "this is not required for qemu to work" just means that QEMU will work fine whether we tell the guest a lie about what's going on with SIGSEGV in one way (saying "it's blocked") or the other (saying "it's not blocked").

Quoting Peter Maydell (<email address hidden>):
> Doing this only for aarch64 targets seems like a bad idea to me -- this
> isn't an aarch64 specific issue. QEMU needs SIGSEGV to go to its own
> handler (so we can unprotect pages we've marked as read-only in order to
> catch guest writes to them so we can throw away invalidated translated
> code), and that's true for all targets. It probably just happens more
> often on the aarch64 target than others you've tested because aarch64
> has a signal-return trampoline on the stack frame, so we'll often see
> that page get translated and thrown away again. (Other targets with a
> trampoline include sparc, cris, openrisc and ppc.)

I see. I've just pushed the customized patch to the archive. We can
switch to the original patchset though. But, I'd also like to see what
ends up hitting upstream.

This bug was fixed in the package qemu - 1.7.0+dfsg-3ubuntu5

---------------
qemu (1.7.0+dfsg-3ubuntu5) trusty; urgency=medium

  [ dann frazier ]
  * Add patches from the susematz tree to avoid intermittent segfaults:
     - ubuntu/signal-added-a-wrapper-for-sigprocmask-function.patch
     - ubuntu/signal-sigsegv-protection-on-do_sigprocmask.patch
     - ubuntu/Don-t-block-SIGSEGV-at-more-places.patch

  [ Serge Hallyn ]
  * Modify do_sigprocmask to only change behavior for aarch64.
    (LP: #1285363)
 -- Serge Hallyn <email address hidden> Thu, 06 Mar 2014 16:15:50 -0600

We've now overhauled the signal handling code in upstream QEMU, and it has its own implementation of the basic idea in the patch from comment 1 (which is "don't let the guest block SIGSEGV").