Qemu Recoverable Assertion when Loading Gecko

[James Tabor]

Head up on this one. It's recoverable by just typing "cont" and it goes on.

(dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL:
C:\ReactOS\system32\oleaut32.dll
WARNING:  MmFlushVirtualMemory at ntoskrnl/mm/ARM3/virtual.c:1044 is
UNIMPLEMENTED!
fixme:(dll/win32/wintrust/register.c:1161) stub
(dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name
C:\ReactOS\system32\mshtml.dll (76650000 -> 014C0000)
(dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL:
C:\ReactOS\System32\setupapi.dll
(ntoskrnl/se/semgr.c:299) SidInToken Calls: 40000
Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at
ntoskrnl/mm/freelist.c line 127
Entered debugger on embedded INT3 at 0x0008:0x80904efe.
kdb:> bt
Eip:
<NTOSKRNL.EXE:104eff (lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0))>
Frames:
<NTOSKRNL.EXE:c283d (ntoskrnl/mm/freelist.c:127 (MmRemoveLRUUserPage@4))>
<NTOSKRNL.EXE:c18de (ntoskrnl/mm/balance.c:134 (MmReleasePageMemoryConsumer@8))>
<NTOSKRNL.EXE:cbf6a (ntoskrnl/mm/section.c:2365 (MmPageOutSectionView@16))>
<NTOSKRNL.EXE:c822c (ntoskrnl/mm/rmap.c:143 (MmPageOutPhysicalAddress@4))>
<NTOSKRNL.EXE:c17a9 (ntoskrnl/mm/balance.c:177 (MmTrimUserMemory))>
<NTOSKRNL.EXE:c141c (ntoskrnl/mm/balance.c:366 (MiBalancerThread@4))>
<NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))>
<NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))>
<NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))>
<fcdebd80>
<NTOSKRNL.EXE:152e5 (ntoskrnl/ke/wait.c:527 (KeWaitForSingleObject@20))>
<NTOSKRNL.EXE:c524e (ntoskrnl/mm/mminit.c:292 (MmMpwThreadMain@4))>
<NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))>
<NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))>
<NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))>
<fce4fab0>
<00000001>
kdb:> cont
Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at
ntoskrnl/mm/freelist.c line 127
Entered debugger on embedded INT3 at 0x0008:0x80904efe.
kdb:> cont
(subsystems/win32/win32k/ntuser/keyboard.c:1066) err: No Window for Translate.
(dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name
xul.dll (10000000 -> 01DB0000)
(dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\system32\
\1.0.0\wine_gecko\xpcom.dll

[James Tabor]

Where is the typo? Is it?

http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/freelist.c?r1=5...

On Thu, Nov 17, 2011 at 6:07 PM, James Tabor [e-mail] wrote:
> Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at
> ntoskrnl/mm/freelist.c line 127
> Entered debugger on embedded INT3 at 0x0008:0x80904efe.

[Cameron Gutman]

On Nov 17, 2011, at 7:07 PM, James Tabor wrote:
> Head up on this one. It's recoverable by just typing "cont" and it goes on.
>
> (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL:
> C:\ReactOS\system32\oleaut32.dll
> WARNING:  MmFlushVirtualMemory at ntoskrnl/mm/ARM3/virtual.c:1044 is
> UNIMPLEMENTED!
> fixme:(dll/win32/wintrust/register.c:1161) stub
> (dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name
> C:\ReactOS\system32\mshtml.dll (76650000 -> 014C0000)
> (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL:
> C:\ReactOS\System32\setupapi.dll
> (ntoskrnl/se/semgr.c:299) SidInToken Calls: 40000
> Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at
> ntoskrnl/mm/freelist.c line 127
> Entered debugger on embedded INT3 at 0x0008:0x80904efe.
> kdb:> bt
> Eip:
> <NTOSKRNL.EXE:104eff (lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0))>
> Frames:
> <NTOSKRNL.EXE:c283d (ntoskrnl/mm/freelist.c:127 (MmRemoveLRUUserPage@4))>
> <NTOSKRNL.EXE:c18de (ntoskrnl/mm/balance.c:134 (MmReleasePageMemoryConsumer@8))>
> <NTOSKRNL.EXE:cbf6a (ntoskrnl/mm/section.c:2365 (MmPageOutSectionView@16))>
> <NTOSKRNL.EXE:c822c (ntoskrnl/mm/rmap.c:143 (MmPageOutPhysicalAddress@4))>
> <NTOSKRNL.EXE:c17a9 (ntoskrnl/mm/balance.c:177 (MmTrimUserMemory))>
> <NTOSKRNL.EXE:c141c (ntoskrnl/mm/balance.c:366 (MiBalancerThread@4))>
> <NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))>
> <NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))>
> <NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))>
>
> <fcdebd80>
> <NTOSKRNL.EXE:152e5 (ntoskrnl/ke/wait.c:527 (KeWaitForSingleObject@20))>
> <NTOSKRNL.EXE:c524e (ntoskrnl/mm/mminit.c:292 (MmMpwThreadMain@4))>
> <NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))>
> <NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))>
> <NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))>
> <fce4fab0>
> <00000001>

This seems pretty bad. We're trying to page out user memory that's not registered in the user PFN bitmap. So either the bitmap is wrong or the MC_USER list is wrong. Any ideas?

Cameron

[Thomas Faber]

On 2011-11-18 09:08, Cameron Gutman wrote:
> On Nov 17, 2011, at 7:07 PM, James Tabor wrote:
> > Head up on this one. It's recoverable by just typing "cont" and it goes on.
> >
> > (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL:
> > C:\ReactOS\system32\oleaut32.dll
> > WARNING:  MmFlushVirtualMemory at ntoskrnl/mm/ARM3/virtual.c:1044 is
> > UNIMPLEMENTED!
> > fixme:(dll/win32/wintrust/register.c:1161) stub
> > (dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name
> > C:\ReactOS\system32\mshtml.dll (76650000 -> 014C0000)
> > (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL:
> > C:\ReactOS\System32\setupapi.dll
> > (ntoskrnl/se/semgr.c:299) SidInToken Calls: 40000
> > Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at
> > ntoskrnl/mm/freelist.c line 127
> > Entered debugger on embedded INT3 at 0x0008:0x80904efe.
> > kdb:> bt
> > Eip:
> > <NTOSKRNL.EXE:104eff (lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0))>
> > Frames:
> > <NTOSKRNL.EXE:c283d (ntoskrnl/mm/freelist.c:127 (MmRemoveLRUUserPage@4))>
> > <NTOSKRNL.EXE:c18de (ntoskrnl/mm/balance.c:134 (MmReleasePageMemoryConsumer@8))>
> > <NTOSKRNL.EXE:cbf6a (ntoskrnl/mm/section.c:2365 (MmPageOutSectionView@16))>
> > <NTOSKRNL.EXE:c822c (ntoskrnl/mm/rmap.c:143 (MmPageOutPhysicalAddress@4))>
> > <NTOSKRNL.EXE:c17a9 (ntoskrnl/mm/balance.c:177 (MmTrimUserMemory))>
> > <NTOSKRNL.EXE:c141c (ntoskrnl/mm/balance.c:366 (MiBalancerThread@4))>
> > <NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))>
> > <NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))>
> > <NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))>
> >
> > <fcdebd80>
> > <NTOSKRNL.EXE:152e5 (ntoskrnl/ke/wait.c:527 (KeWaitForSingleObject@20))>
> > <NTOSKRNL.EXE:c524e (ntoskrnl/mm/mminit.c:292 (MmMpwThreadMain@4))>
> > <NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))>
> > <NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))>
> > <NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))>
> > <fce4fab0>
> > <00000001>
>
> This seems pretty bad. We're trying to page out user memory that's not
> registered in the user PFN bitmap. So either the bitmap is wrong or the
> MC_USER list is wrong. Any ideas?

Let's not rule out the possibility that the bitmap functions are broken btw ;)

Timo suggested making a test for them a while ago -- I've started, but it's not
finished yet. Doesn't look too good though IIRC. I'll try and get it done and
committed.

*heavily hopes that might fix some Mm problems*

I fear Mm likely has bigger problems than those functions though, so there might
be something else wrong here, too.

-Tom

[Cameron Gutman]

> Let's not rule out the possibility that the bitmap functions are broken btw ;)

I doubt this is the case, since we use bitmap functions all over ROS. I know we use them to manage ports in TCP/IP and also to manage map registers for DMA in HAL. Neither of those uses display any signs of malfunctioning in the bitmap functions. There are also many more uses in Cm and Ldr. I just doubt that a severe bug that shows up so regularly using standard bitmap APIs could go unfixed with so many uses of those functions.

Plus, we already have an Rtl bitmap winetest in ntdll which passes all tests.

Cameron

[Aleksey Bragin]

On 18.11.2011 19:35, Cameron Gutman wrote:
> > Let's not rule out the possibility that the bitmap functions are broken btw ;)
>
> I doubt this is the case, since we use bitmap functions all over ROS. I know we use them to manage ports in TCP/IP and also to manage map registers for DMA in HAL. Neither of those uses display any signs of malfunctioning in the bitmap functions. There are also many more uses in Cm and Ldr. I just doubt that a severe bug that shows up so regularly using standard bitmap APIs could go unfixed with so many uses of those functions.
>
> Plus, we already have an Rtl bitmap winetest in ntdll which passes all tests.

Once, I had to add yet another test to fix the behavior. It also looked 
very good back then, with the exception that bitmaps were not used that 
much in ReactOS and issue did not manifest itself.

As for now, I'm 99% sure bitmap code works as expected.

WBR,
Aleksey.

[Jérôme Gardou]

Le 18/11/2011 01:07, James Tabor a écrit :
> Head up on this one. It's recoverable by just typing "cont" and it goes on.
>
> (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL:
> C:\ReactOS\system32\oleaut32.dll
> WARNING:  MmFlushVirtualMemory at ntoskrnl/mm/ARM3/virtual.c:1044 is
> UNIMPLEMENTED!
> fixme:(dll/win32/wintrust/register.c:1161) stub
> (dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name
> C:\ReactOS\system32\mshtml.dll (76650000 ->  014C0000)
> (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL:
> C:\ReactOS\System32\setupapi.dll
> (ntoskrnl/se/semgr.c:299) SidInToken Calls: 40000
> Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at
> ntoskrnl/mm/freelist.c line 127
> Entered debugger on embedded INT3 at 0x0008:0x80904efe.
> kdb:>  bt
> Eip:
> <NTOSKRNL.EXE:104eff (lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0))>
> Frames:
> <NTOSKRNL.EXE:c283d (ntoskrnl/mm/freelist.c:127 (MmRemoveLRUUserPage@4))>
> <NTOSKRNL.EXE:c18de (ntoskrnl/mm/balance.c:134 (MmReleasePageMemoryConsumer@8))>
> <NTOSKRNL.EXE:cbf6a (ntoskrnl/mm/section.c:2365 (MmPageOutSectionView@16))>
> <NTOSKRNL.EXE:c822c (ntoskrnl/mm/rmap.c:143 (MmPageOutPhysicalAddress@4))>
> <NTOSKRNL.EXE:c17a9 (ntoskrnl/mm/balance.c:177 (MmTrimUserMemory))>
> <NTOSKRNL.EXE:c141c (ntoskrnl/mm/balance.c:366 (MiBalancerThread@4))>
> <NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))>
> <NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))>
> <NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))>
>
> <fcdebd80>
> <NTOSKRNL.EXE:152e5 (ntoskrnl/ke/wait.c:527 (KeWaitForSingleObject@20))>
> <NTOSKRNL.EXE:c524e (ntoskrnl/mm/mminit.c:292 (MmMpwThreadMain@4))>
> <NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))>
> <NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))>
> <NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))>
> <fce4fab0>
> <00000001>
> kdb:>  cont
> Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at
> ntoskrnl/mm/freelist.c line 127
> Entered debugger on embedded INT3 at 0x0008:0x80904efe.
> kdb:>  cont
> (subsystems/win32/win32k/ntuser/keyboard.c:1066) err: No Window for Translate.
> (dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name
> xul.dll (10000000 ->  01DB0000)
> (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\system32\
> \1.0.0\wine_gecko\xpcom.dll
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

Hi James!

I put this ASSERT here to check, as Cameron just pointed, that we don't 
remove a PFN entry from user bitmap when it already has or never was in 
it. I hoped someone would trigger it. I think you deserve a "thank you" :-)

So let's just fix this one, it can't do any harm.

Btw, do you mean by "loading gecko", the very instant when mshtml.dll 
gets registered in 3rd stage? Isn't it startling how it coincides with 
bug 5857 ?

Best regards.
Jérôme

[James Tabor]

Hi!

2011/11/18 Jérôme Gardou [e-mail]:
> Hi James!
>
> I put this ASSERT here to check, as Cameron just pointed, that we don't
> remove a PFN entry from user bitmap when it already has or never was in it.
> I hoped someone would trigger it. I think you deserve a "thank you" :-)
>
> So let's just fix this one, it can't do any harm.
>
> Btw, do you mean by "loading gecko", the very instant when mshtml.dll gets
> registered in 3rd stage? Isn't it startling how it coincides with bug 5857 ?
>
> Best regards.
> Jérôme

Something the installer was doing I guess, in most cases more than 10
hits at this point. Running DOSEmu hits it every time to the point of
having to kill Qemu. The fix for me last night was commenting the
assert out. To continue my testing.

Hoping I'm not the only one but if I am, QEMU emulator version 0.13.0
(qemu-kvm-0.13.0) Fedroa 12/13/14. Haven't tested Slackware 13.x and
hardware yet.

Thanks,
James

[Jérôme Gardou]

Le 18/11/2011 21:08, James Tabor a écrit :
> Hi!
>
> 2011/11/18 Jérôme [e-mail]:
> > Hi James!
> >
> > I put this ASSERT here to check, as Cameron just pointed, that we don't
> > remove a PFN entry from user bitmap when it already has or never was in it.
> > I hoped someone would trigger it. I think you deserve a "thank you" :-)
> >
> > So let's just fix this one, it can't do any harm.
> >
> > Btw, do you mean by "loading gecko", the very instant when mshtml.dll gets
> > registered in 3rd stage? Isn't it startling how it coincides with bug 5857 ?
> >
> > Best regards.
> > Jérôme
>
> Something the installer was doing I guess, in most cases more than 10
> hits at this point. Running DOSEmu hits it every time to the point of
> having to kill Qemu. The fix for me last night was commenting the
> assert out. To continue my testing.
>
> Hoping I'm not the only one but if I am, QEMU emulator version 0.13.0
> (qemu-kvm-0.13.0) Fedroa 12/13/14. Haven't tested Slackware 13.x and
> hardware yet.
>
> Thanks,
> James
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

Out of curiosity, how much RAm did you allocate for your VM ?

[Bernd Blaauw]

Op 18-11-2011 21:12, Jérôme Gardou schreef:
> Out of curiosity, how much RAm did you allocate for your VM ?

running with only 64 (or 48) MB of RAM is a nice way of 
detecting/finding issues. Trunk seems to reliably install/act on a 
minimum of 96MB, while for example 0.3.11 only needed 48MB (see bug 
6526). 0.2.5 was the last version meeting the documented amount of 32MB.
[ http://www.reactos.org/wiki/Installing_ReactOS ]

[James Tabor]

2011/11/18 Jérôme Gardou [e-mail]:
> Out of curiosity, how much RAm did you allocate for your VM ?

Just at 127m.

[James Tabor]

Hi,
@ wrk!

Here is the data from the patch posted 9565.

Results:
http://www.reactos.org/paste/index.php/9566/

Thanks,
James