From patchwork Mon Oct 17 14:09:07 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bob Breuer X-Patchwork-Id: 120212 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [140.186.70.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 52F6CB6F97 for ; Tue, 18 Oct 2011 01:08:18 +1100 (EST) Received: from localhost ([::1]:60282 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFnrT-0001Kc-Vm for incoming@patchwork.ozlabs.org; Mon, 17 Oct 2011 10:08:15 -0400 Received: from eggs.gnu.org ([140.186.70.92]:57976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RFnr9-0000oZ-48 for qemu-devel@nongnu.org; Mon, 17 Oct 2011 10:08:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RFnr3-0004MW-8A for qemu-devel@nongnu.org; Mon, 17 Oct 2011 10:07:55 -0400 Received: from mail.mc.net ([209.172.128.24]:45111) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RFnr3-0004Ll-4D for qemu-devel@nongnu.org; Mon, 17 Oct 2011 10:07:49 -0400 Received: (qmail 7050 invoked by uid 420); 17 Oct 2011 14:07:49 -0000 Received: from unknown (HELO ?127.0.0.1?) (breuerr@209.172.177.18) by mail.mc.net with SMTP; 17 Oct 2011 14:07:49 -0000 Message-ID: <4E9C3703.3040109@mc.net> Date: Mon, 17 Oct 2011 09:09:07 -0500 From: Bob Breuer User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mark Cave-Ayland References: <4E9BB180.6080506@mc.net> <4E9C0497.2000605@siriusit.co.uk> In-Reply-To: <4E9C0497.2000605@siriusit.co.uk> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-Received-From: 209.172.128.24 Cc: qemu-devel Subject: Re: [Qemu-devel] qemu-system-sparc io-thread segfault on win32 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Mark Cave-Ayland wrote: > On 17/10/11 05:39, Bob Breuer wrote: > >> I'm getting a segfault from qemu-system-sparc with the io thread enabled >> on win32. This is with the latest mingw (gcc 4.6.1). mipsel also >> fails, but i386 is ok. I haven't checked any of the other system >> targets, but they might also show this problem. >> >> git bisect points to commit cea5f9a cpu-exec.c: avoid AREG0 use, but >> that would seem to only expose the bug instead of creating it. In >> cpu_exec(), assigning any valid pointer to ebp before setjmp will get it >> working again. It looks like a bogus value in ebp at the time of setjmp >> will cause longjmp to abort on win32. >> >> Here's some output from gdb for the crash: >> Starting program: >> d:\qemu\build-mingw\sparc-softmmu\qemu-system-sparc.exe >> -m 64 -L ./qemu-git/pc-bios >> [New Thread 2128.0x664] >> [New Thread 2128.0x5d4] >> [New Thread 2128.0x6dc] >> [Switching to Thread 2128.0x6dc] >> >> Breakpoint 1, 0x00514a30 in _setjmp () >> (gdb) info registers >> eax 0x1989b7c 26778492 >> ecx 0x1982008 26746888 >> edx 0x0 0 >> ebx 0x1982008 26746888 >> esp 0x378fe00 0x378fe00 >> ebp 0xfffffffe 0xfffffffe >> esi 0x0 0 >> edi 0x1982008 26746888 >> eip 0x514a30 0x514a30<_setjmp> >> eflags 0x202 [ IF ] >> cs 0x1b 27 >> ss 0x23 35 >> ds 0x23 35 >> es 0x23 35 >> fs 0x38 56 >> gs 0x0 0 >> (gdb) c >> Continuing. >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x7800bd65 in abnormal_termination () from >> C:\WINNT\system32\msvcrt.dll >> (gdb) bt >> #0 0x7800bd65 in abnormal_termination () from >> C:\WINNT\system32\msvcrt.dll >> #1 0x0378ffa4 in ?? () >> Backtrace stopped: previous frame inner to this frame (corrupt stack?) >> >> Bob > > Hi Bob, > > I wonder if you're being caught out by some of the missing > free()/g_free() substitutions? (patches for some of which have been > posted to the list over the last few days). I'm fairly sure from > previous experience that Windows has a limitation in that the DLL that > claimed the memory must be the one to free it, otherwise you get some > strange internal exceptions. > I don't think this is a free/g_free issue. If I use the following patch, then I at least get the openbios messages: Google finds a mention of longjmp failing with -fomit-frame-pointer: http://lua-users.org/lists/lua-l/2005-02/msg00158.html Looks like gcc 4.6 turns on -fomit-frame-pointer by default. Bob diff --git a/cpu-exec.c b/cpu-exec.c index a9fa608..dfbd6ea 100644 --- a/cpu-exec.c +++ b/cpu-exec.c @@ -180,6 +180,7 @@ static void cpu_handle_debug_exception(CPUState /* main execution loop */ volatile sig_atomic_t exit_request; +register void *ebp asm("ebp"); int cpu_exec(CPUState *env) { @@ -233,6 +234,8 @@ int cpu_exec(CPUState *env) /* prepare setjmp context for exception handling */ for(;;) { + int dummy = 0; + ebp = &dummy; if (setjmp(env->jmp_env) == 0) { /* if an exception is pending, we execute it here */ if (env->exception_index >= 0) {