<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
First sorry for posting on the developers list without being a
developer, but since vbox-user didn't help as well as irc channels,
I try it here :)<br>
<br>
I'm a ReactOS developer working on the x64 port of ReactOS. I just
stumbled upon something that seems to be a very strange VBox bug:<br>
<br>
Under some circumstances an int 3 will cause the RIP value that is
pushed on the stack to point *at* the 0xCC instead of pointing
*after* it.<br>
I verified this by putting a HLT instruction at the int 3 handler
and then checked with the vbox debugger (log attached at the end)<br>
<br>
I also tried this with int 2c, there the problem doesn't appear.<br>
<br>
This behaviour occurred as soon as I was accessing a certain range
of memory. Higher level page directories were already set up and I
could set up a PTE without any problem, the bug occured after I
accessed the mapped page.<br>
I could map any physical page to the PTE without changing the
behaviour. Also reloading cr3 before and after mapping the PTE
didn't change anything. The VA range where it happened is the range
of one PDE. <br>
Changing the physical page for that PDE could "fix" the problem.
Some pages worked, while others didn't.<br>
The appearance of the bug is also sensitive to other things:<br>
- putting the int 3 at different locations
<br>
- excluding a range of pages from being used by the OS loader
(marking as firmware)
<br>
- double mapping of page tables
<br>
<br>
The problem also happened directly after mapping the PTE.
<br>
As soon as the behaviour starts it will continue this way, ie when
continuing with a fixed rip the next int 3 will also push an rip on
the stack that points at the 0xCC
<br>
<br>
I currently added an ugly hack to the trap dispatcher code that
checks for this condition and corrects the RIP value in the trap
frame.<br>
<br>
I would accept that it is a bug in my code, but I would like to
understand what I did wrong. And I also wonder how it could lead to
something as strange as a wrong rip pushed on the stack after an int
3. <br>
So any hints what the reason might be are very appreciated. I can
provide any additional information requested.<br>
<br>
Btw, this is on vbox 4.1.8.r75467 with and without PAE/NX / nested
paging enabled. Host CPU is an AMD Athlon 64 x2.<br>
<br>
WBR,<br>
Timo<br>
<br>
Vbox debug log:<br>
<blockquote><tt>Welcome to the VirtualBox Debugger!<br>
Current VM is 00920000, CPU #0<br>
VBoxDbg> stop<br>
<br>
dbgf event: VM 0000000000920000 is halted! (other)<br>
eax=0000002f ebx=00000000 ecx=ffc00000 edx=00000002 esi=fee0fae5
edi=00005060<br>
eip=0052b23a esp=00584058 ebp=00000000 iopl=0 nv up di pl zr na
po nc<br>
cs=0010 ds=002b es=002b fs=0053 gs=002b ss=0018
eflags=00000046<br>
0010:0052b23a 48 c7 c1 45 23 01 00 mov rcx,
00000000000012345h<br>
VBoxDbg> rg64<br>
rax=000000000000002f rbx=0000000000000000 rcx=ffffffffffc00000
rdx=0000000000000002<br>
rsi=00000000fee0fae5 rdi=0000000000005060 r8 =0000000000000000
r9 =fffff80000583fa0<br>
r10=0000000000000000 r11=fffff800005a1080 r12=0000000000000000
r13=0000000000000000<br>
r14=0000000000000000 r15=0000000000000000 iopl=0 nv up di pl zr
na po nc<br>
rip=fffff8000052b23a rsp=<b>fffff80000584058</b>
rbp=0000000000000000<br>
cs=0010 ds=002b es=002b fs=0053 gs=002b
ss=0018 rflags=00000046<br>
%fffff8000052b23a 48 c7 c1 45 23 01 00 mov rcx,
00000000000012345h<br>
VBoxDbg> dq <b>fffff80000584058</b><br>
%fffff80000584058: <b>fffff8000059aeb4</b> 0000000000000010<br>
%fffff80000584068: 0000000000000046 fffff80000584080<br>
%fffff80000584078: 0000000000000018 fffff80000598000<br>
%fffff80000584088: fffff800005a1080 fffff800005840f0<br>
%fffff80000584098: fffff800005840a4 000000b600000080<br>
%fffff800005840a8: 0000000000001003 fffff6ffffffe000<br>
VBoxDbg> u <b>fffff8000059aeb4</b><br>
%<b>fffff8000059aeb4 cc int3</b><br>
%fffff8000059aeb5 48 8b 05 0c 43 00 00 mov rax, qword
[00000430ch wrt rip]<br>
%fffff8000059aebc 8b 40 04 mov eax, dword
[rax+004h]<br>
%fffff8000059aebf 2d 00 10 00 00 sub eax, 000001000h<br>
%fffff8000059aec4 89 44 24 20 mov dword [rsp+020h],
eax<br>
%fffff8000059aec8 8b 44 24 20 mov eax, dword
[rsp+020h]<br>
%fffff8000059aecc 33 d2 xor edx, edx<br>
%fffff8000059aece b9 04 00 00 00 mov ecx, 000000004h<br>
%fffff8000059aed3 48 f7 f1 div rcx<br>
%fffff8000059aed6 48 8b c8 mov rcx, rax<br>
VBoxDbg> <br>
</tt></blockquote>
<br>
<br>
</body>
</html>