From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lit1L-0002Ke-AD for qemu-devel@nongnu.org; Sun, 15 Mar 2009 12:17:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lit1G-0002HL-Fx for qemu-devel@nongnu.org; Sun, 15 Mar 2009 12:17:02 -0400 Received: from [199.232.76.173] (port=44638 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lit1G-0002H3-7P for qemu-devel@nongnu.org; Sun, 15 Mar 2009 12:16:58 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]:50349) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lit1F-0007zD-No for qemu-devel@nongnu.org; Sun, 15 Mar 2009 12:16:58 -0400 Received: from localhost ([127.0.0.1] ident=stefan) by flocke.weilnetz.de with esmtp (Exim 4.69) (envelope-from ) id 1Lit19-0001rr-9S for qemu-devel@nongnu.org; Sun, 15 Mar 2009 17:16:51 +0100 Message-ID: <49BD29F2.9000400@mail.berlios.de> Date: Sun, 15 Mar 2009 17:16:50 +0100 From: Stefan Weil MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: SIGSEGV on Windows with KQEMU enabled References: <200903150042.58341.paul@codesourcery.com> In-Reply-To: <200903150042.58341.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Paul Brook schrieb: >>> But really funny think is the change that triggers the bug is precisely >>> this: -Monitor *cur_mon; >>> +Monitor *cur_mon = NULL; >>> >>> Obviously, kqemu is happier having garbage in the cur_mon than NULL >>> >> I rather expect that to _hide_ the bug. The "garbage" might be a >> left-over from the heap. >> > > This change does precisely nothing. In C all global and static variables are > implicitly zero initialized. > > Paul > > > This change changes the location of variable cur_mon from BSS to DATA segment. For buggy code, such changes surely can have an effect. Maybe some other variable in data which is located before cur_mon destroys cur_mon. Running in gdb with a hardware watchpoint on any change of cur_mon might help to see if cur_mon is overwritten. Stefan