[Qemu-devel] Something is probably wrong with "int 3"

[Qemu-devel] Something is probably wrong with "int 3"

[Alexander E. Patrakov]

Hello, I suspect the following to be a bug in qemu.

Earlier in the Firefox-related thread, I attached the crash report from
DrWatson. It contained the following lines at the end:

function: DbgBreakPoint
        77fa144b cc               int     3
FAULT-> 77fa144c c3               ret

However, examples of similar faults from Microsoft Knowledge Base,

http://support.microsoft.com/kb/252837/EN-US/
http://support.microsoft.com/kb/194594/EN-US/
http://support.microsoft.com/kb/189474/EN-US/

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?


-- 
Alexander E. Patrakov

Re: [Qemu-devel] Something is probably wrong with "int 3"

[André Braga]

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

[Qemu-devel] Re: Something is probably wrong with "int 3"

[Alexander E. Patrakov]

Andr? Braga wrote:

> 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.

Yes, in this case DrWatson pops up.

> 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?)

Look at the crash dump - the DbgBreakPoint() is called from
kernel32!SetThreadExecutionState, i.e. from deep inside the Windows kernel.
Firefox just happens to be an easy way to trigger this. And yes, the error
that causes Firefox to crash is actually before this. Consider my first
mail in this thread as additional bug report, unrelated to Firefox in any
way. I know that fixing "wrong fault address after int 3" will not cure
Firefox, but it's a bug anyway, if I understand that correctly.

> 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?

It is the official build, and it runs perfectly on old i586 machines.

-- 
Alexander E. Patrakov

Re: [Qemu-devel] Re: Something is probably wrong with "int 3"

[Johannes Schindelin]

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
> > <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?

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.

> 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.

Ciao,
Dscho

[Qemu-devel] Re: Something is probably wrong with "int 3"

[Alexander E. Patrakov]

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
>> > <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?
> 
> 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

[Qemu-devel] Re: Something is probably wrong with "int 3"

[Alexander E. Patrakov]

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
>>> > <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?
>> 
>> 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 <windows.h>

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