[ros-dev] Trunk is broken

[Eric Kohl]

Gabriel ilardi wrote:
> Hi all,
> 
> Just that this doesn't get lost, trunk's broken in two ways:
> 
> 1) after *45640* you get the "CMP_WaitNoPending..."  in 2nd stage in 
> vbox being unable to proceed. Bug 4142: 
> http://www.reactos.org/bugzilla/show_bug.cgi?id=4142
> 
> 2) after *45645* installation stops at 1st stage with an assert:
> 
> Assertion 'GuardedMutex->Owner != Thread' failed at ntoskrnl\include\/internal/k                                                                                                                                                             e_x.h line 1596
> Entered debugger on embedded INT3 at 0x0008:0x808dc52e.
> kdb:> PuTTYbt
> Eip:
> <ntoskrnl.exe:dc52f (lib\rtl\i386\debug_asm.S:33 (DbgBreakPoint at 0))>
> Frames:
> <ntoskrnl.exe:9aaa4 (ntoskrnl/include//internal/ke_x.h:1596 (MmNotPresentFault at 1                                                                                                                                                             2))>
> <ntoskrnl.exe:9b6e3 (ntoskrnl/mm/mmfault.c:298 (MmAccessFault at 16))>
> <ntoskrnl.exe:66fb (ntoskrnl/ke/i386/traphdlr.c:1132 (@KiTrap0EHandler at 4))>
> <ntoskrnl.exe:1b21c (ntoskrnl/cc/view.c:463 (CcRosLookupCacheSegment at 8))>
> <ntoskrnl.exe:ac31a (ntoskrnl/mm/section.c:1251 (MmNotPresentFaultSectionView at 16                                                                                                                                                             ))>
> <ntoskrnl.exe:9adb9 (ntoskrnl/mm/mmfault.c:219 (MmNotPresentFault at 12))>
> <ntoskrnl.exe:9b6e3 (ntoskrnl/mm/mmfault.c:298 (MmAccessFault at 16))>
> <ntoskrnl.exe:66fb (ntoskrnl/ke/i386/traphdlr.c:1132 (@KiTrap0EHandler at 4))>
> <b085a008>
> <ntoskrnl.exe:601e
>                   <ntoskrnl.exe:6412 (ntoskrnl/ke/i386/traphdlr.c:1517 (@KiFastC                                                                                                                                                             allEntryHandler at 8))>
> <00000000>
> kdb:>
> 
> Thanks.

I'll revert the remaining parts of the *45640* issue. It seems the 
service manager and services are not ready for these improvements yet.


Regards
Eric