From patchwork Thu Oct 7 12:56:28 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Clarke <656285@bugs.launchpad.net> X-Patchwork-Id: 67057 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 70ACFB6F10 for ; Fri, 8 Oct 2010 00:11:14 +1100 (EST) Received: from localhost ([127.0.0.1]:38707 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P3qBS-0002pp-4x for incoming@patchwork.ozlabs.org; Thu, 07 Oct 2010 09:06:54 -0400 Received: from [140.186.70.92] (port=37327 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P3qA8-0002Xx-2q for qemu-devel@nongnu.org; Thu, 07 Oct 2010 09:05:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P3qA5-0005pa-BQ for qemu-devel@nongnu.org; Thu, 07 Oct 2010 09:05:31 -0400 Received: from adelie.canonical.com ([91.189.90.139]:44159) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P3qA5-0005ov-4d for qemu-devel@nongnu.org; Thu, 07 Oct 2010 09:05:29 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by adelie.canonical.com with esmtp (Exim 4.69 #1 (Debian)) id 1P3qA4-0006yC-2N for ; Thu, 07 Oct 2010 14:05:28 +0100 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 0C65E2E8058 for ; Thu, 7 Oct 2010 13:05:28 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 07 Oct 2010 12:56:28 -0000 From: Stephen Clarke <656285@bugs.launchpad.net> To: qemu-devel@nongnu.org X-Launchpad-Bug: product=qemu; status=New; importance=Undecided; assignee=None; X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: stephen-clarke X-Launchpad-Bug-Reporter: Stephen Clarke (stephen-clarke) X-Launchpad-Bug-Modifier: Stephen Clarke (stephen-clarke) References: <20101007125628.8009.23815.malonedeb@soybean.canonical.com> Message-Id: <20101007125628.8009.23815.malonedeb@soybean.canonical.com> X-Launchpad-Message-Rationale: Subscriber (QEMU) @qemu-devel-ml Precedence: bulk X-Generated-By: Launchpad (canonical.com); Revision="None"; Instance="initZopeless config overlay" X-Launchpad-Hash: 6589d5f13dae75e2d443dcbedb51b2252d4792a8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: [Qemu-devel] [Bug 656285] [NEW] arm-semi mishandling SYS_HEAPINFO X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Reply-To: Bug 656285 <656285@bugs.launchpad.net> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Public bug reported: I am running qemu-arm on a 32-bit fedora-7 i386 machine: $ /home/bri0633/users/clarkes/qemu/build/arm-linux-user/qemu-arm --version qemu-arm version 0.12.3, Copyright (c) 2003-2008 Fabrice Bellard When I try to run an arm semi-hosted executable, I sometimes get unexpected segv and sometimes not, depending on the executable. The symptom is: $ /home/bri0633/users/clarkes/qemu/build/arm-linux-user/qemu-arm -cpu cortex-a9 -- a.out qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault It appear to be because of the handling of the SYS_HEAPINFO syscall in arm-semi.c. There it tries to allocate 128M for the heap by calling do_brk() which calls target_mmap(). This is the DEBUG_MMAP diagnostic: mmap: start=0x00009000 len=0x08001000 prot=rw- flags=MAP_FIXED MAP_ANON MAP_PRIVATE fd=0 offset=00000000 but this mmap is failing because there are shared libraries (and the gate page) mapped there: $ ldd /home/bri0633/users/clarkes/qemu/build/arm-linux-user/qemu-arm linux-gate.so.1 => (0x00880000) librt.so.1 => /lib/librt.so.1 (0x03409000) libpthread.so.0 => /lib/libpthread.so.0 (0x00d7d000) libm.so.6 => /lib/libm.so.6 (0x00d4b000) libc.so.6 => /lib/libc.so.6 (0x00bf5000) /lib/ld-linux.so.2 (0x00bd6000) However, it seems that the code in arm-semi.c does not interpret the result of do_brk() correctly, and thinks that the mapping succeeded. The following patch appears to fix the problem: $ diff -u arm-semi.c.orig arm-semi.c Do you think this is a genuine bug? Steve. --- arm-semi.c.orig 2010-09-21 13:19:15.000000000 +0100 +++ arm-semi.c 2010-10-07 13:23:13.000000000 +0100 @@ -475,7 +475,7 @@ /* Try a big heap, and reduce the size if that fails. */ for (;;) { ret = do_brk(limit); - if (ret != -1) + if (ret == limit) break; limit = (ts->heap_base >> 1) + (limit >> 1); } Do you think this is a genuine bug? Steve. ** Affects: qemu Importance: Undecided Status: New -- arm-semi mishandling SYS_HEAPINFO https://bugs.launchpad.net/bugs/656285 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I am running qemu-arm on a 32-bit fedora-7 i386 machine: $ /home/bri0633/users/clarkes/qemu/build/arm-linux-user/qemu-arm --version qemu-arm version 0.12.3, Copyright (c) 2003-2008 Fabrice Bellard When I try to run an arm semi-hosted executable, I sometimes get unexpected segv and sometimes not, depending on the executable. The symptom is: $ /home/bri0633/users/clarkes/qemu/build/arm-linux-user/qemu-arm -cpu cortex-a9 -- a.out qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault It appear to be because of the handling of the SYS_HEAPINFO syscall in arm-semi.c. There it tries to allocate 128M for the heap by calling do_brk() which calls target_mmap(). This is the DEBUG_MMAP diagnostic: mmap: start=0x00009000 len=0x08001000 prot=rw- flags=MAP_FIXED MAP_ANON MAP_PRIVATE fd=0 offset=00000000 but this mmap is failing because there are shared libraries (and the gate page) mapped there: $ ldd /home/bri0633/users/clarkes/qemu/build/arm-linux-user/qemu-arm linux-gate.so.1 => (0x00880000) librt.so.1 => /lib/librt.so.1 (0x03409000) libpthread.so.0 => /lib/libpthread.so.0 (0x00d7d000) libm.so.6 => /lib/libm.so.6 (0x00d4b000) libc.so.6 => /lib/libc.so.6 (0x00bf5000) /lib/ld-linux.so.2 (0x00bd6000) However, it seems that the code in arm-semi.c does not interpret the result of do_brk() correctly, and thinks that the mapping succeeded. The following patch appears to fix the problem: $ diff -u arm-semi.c.orig arm-semi.c --- arm-semi.c.orig 2010-09-21 13:19:15.000000000 +0100 +++ arm-semi.c 2010-10-07 13:23:13.000000000 +0100 @@ -475,7 +475,7 @@ /* Try a big heap, and reduce the size if that fails. */ for (;;) { ret = do_brk(limit); - if (ret != -1) + if (ret == limit) break; limit = (ts->heap_base >> 1) + (limit >> 1); }