From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33)
	id 1Clpxp-00047T-RJ
	for qemu-devel@nongnu.org; Tue, 04 Jan 2005 09:47:13 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33)
	id 1Clpxn-00045x-0j
	for qemu-devel@nongnu.org; Tue, 04 Jan 2005 09:47:11 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.33) id 1Clpxm-00045c-Kl
	for qemu-devel@nongnu.org; Tue, 04 Jan 2005 09:47:10 -0500
Received: from [64.233.170.200] (helo=rproxy.gmail.com)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1ClpmC-0003Jm-TE
	for qemu-devel@nongnu.org; Tue, 04 Jan 2005 09:35:13 -0500
Received: by rproxy.gmail.com with SMTP id z35so124999rne
	for <qemu-devel@nongnu.org>; Tue, 04 Jan 2005 06:35:11 -0800 (PST)
Message-ID: <2ad73a0501040635d2dc2c3@mail.gmail.com>
Date: Tue, 4 Jan 2005 12:35:11 -0200
From: =?ISO-8859-1?Q?Andr=E9_Braga?= <meianoite@gmail.com>
Subject: Re: [Qemu-devel] Something is probably wrong with "int 3"
In-Reply-To: <cre4fv$at9$1@sea.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <cre4fv$at9$1@sea.gmane.org>
Reply-To: =?ISO-8859-1?Q?Andr=E9_Braga?= <meianoite@gmail.com>,
	qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

On Tue, 04 Jan 2005 18:09:32 +0500, Alexander E. Patrakov
<patrakov@ums.usu.ru> 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?

Uh... INT 3 is the debugger services interrupt. It usually triggers a
resident debugger so it attaches to the calling process.

It might be that Firefox reached a situation where it knew it would
crash, so it called the debugger first and then failed returning to an
invalid address (maybe the stack was corrupt?)

Anyway, I don't think that QEMU handles INT 3 at all; the fault must
be somewhere else. Are you absolutely sure your Firefox build isn't
calling MMX/SSE instructions? Is it a contributed build or is it
official?


-- 
"The user-friendly computer is a red herring. The user-friendliness of
a book just makes it easier to turn pages. There's nothing
user-friendly about learning to read."
Alan Kay