From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cm8Zo-0007ZY-6l for qemu-devel@nongnu.org; Wed, 05 Jan 2005 05:39:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cm8YJ-0007CO-HR for qemu-devel@nongnu.org; Wed, 05 Jan 2005 05:38:08 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cm8FH-0005w9-Ek for qemu-devel@nongnu.org; Wed, 05 Jan 2005 05:18:27 -0500 Received: from [80.91.229.2] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cm83i-0001tf-MN for qemu-devel@nongnu.org; Wed, 05 Jan 2005 05:06:30 -0500 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Cm83h-0004Jg-00 for ; Wed, 05 Jan 2005 11:06:29 +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 11:06:29 +0100 Received: from patrakov by inet.ycc.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Jan 2005 11:06:29 +0100 From: "Alexander E. Patrakov" Date: Wed, 05 Jan 2005 15:07:38 +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 Alexander E. Patrakov wrote: > 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. Well, I am totally confused. The test program is: #include int APIENTRY WinMain(HINSTANCE p1, HINSTANCE p2, LPSTR p3, int p4) { DebugBreak(); return 0; } As expected, this crashes, and the fault is at "int 3" in qemu. So it looks like no bug is here. But then, why does Firefox produce a visible fault at "ret", not at "int 3"? Maybe there's some exception handler that handles the first exception on "int 3" and then the second, unhandled, exception is produced on "ret"? -- Alexander E. Patrakov