From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cm5pS-0000cJ-Vm for qemu-devel@nongnu.org; Wed, 05 Jan 2005 02:43:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cm5pS-0000bo-GI for qemu-devel@nongnu.org; Wed, 05 Jan 2005 02:43:38 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cm5pS-0000bf-Cy for qemu-devel@nongnu.org; Wed, 05 Jan 2005 02:43:38 -0500 Received: from [80.91.229.2] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cm5dz-0001I3-7v for qemu-devel@nongnu.org; Wed, 05 Jan 2005 02:31:47 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Cm5dy-0005qO-00 for ; Wed, 05 Jan 2005 08:31:46 +0100 Received: from inet.ycc.ru ([217.148.52.177]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Jan 2005 08:31:46 +0100 Received: from patrakov by inet.ycc.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Jan 2005 08:31:46 +0100 From: "Alexander E. Patrakov" Date: Wed, 05 Jan 2005 12:32:52 +0500 Message-ID: References: <2ad73a0501040635d2dc2c3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Sender: news Subject: [Qemu-devel] Re: Something is probably wrong with "int 3" 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 Johannes Schindelin wrote: > Hi, > > On Tue, 4 Jan 2005, Alexander E. Patrakov wrote: > >> Andr? Braga wrote: >> >> > On Tue, 04 Jan 2005 18:09:32 +0500, Alexander E. Patrakov >> > wrote: >> >> clearly state that the fault is at the "int 3" instruction, not at >> >> "ret". Can anyone explain this difference? Is this a bug in qemu? > > That is quite normal. As int 3 is already executed when the pop up is > triggered, the program counter in that frame points to the next insn. I will nevertheless check that by means of writing and executing a test program. >> Look at the crash dump - the DbgBreakPoint() is called from >> kernel32!SetThreadExecutionState, i.e. from deep inside the Windows >> kernel. > > If DbgBreakPoint() is called, this normally means that a DebugAssertion > was called, which is not fulfilled. > > Can you inspect what's going on in SetThreadExecutionState before the > INT 3 (I mean disassemble it and tell us what Windows is trying to do)? > This should help understand the problem. I tried to do that and failed. The instruction just before the return address from DbgBreakPoint is: "call [ebp+08]" with a "mov ebp, esp" some lines above, so I have to hunt down how did the address of DbgBreakPoint make onto the stack. However, all references to DbgBreakPoint in kernel32.dll are (as far as W32Dasm 8.93 can tell) of the form "call DbgBreakPoint", not "mov" or "lea". So I have to investigate some other DLL. Since in VMware a dialog sonfirming my intention to send possibly confidential information appears instead of the Firefox crash, I suppose that user32.dll or gdi32.dll is relevant. -- Alexander E. Patrakov