Hi,
I think your crash has nothing to do with the to many opened handles from csrss. Currently each created process doesn't free one directory object (tag DIRT). This is the real problem. One 'ros on ros compiling run' creates 40,000 process's. Each directory object has a size of 60 byte. With the overhead, it does eat up nearly 3MB of the non paged pool. Two days are 40 runs (I assume a fast computer). 40*3MB = 120MB is the limit of the non paged pool.
- Hartmut
James Tabor wrote:
Hi!
This was not unexpected. I noticed last night csrss was over 11000K bytes in size. The memory leak in csrss is handles, some of them do not close. So the number goes from ~80 to 2000+ after two days of building ros over and over. You can try to close the windows but the handle count is the same so~~~~~.
Thanks, James
(KERNEL32:mem/global.c:412) Memory Load: 59 (KERNEL32:mem/global.c:412) Memory Load: 59 (mm/npool.c:1626) Trying to allocate 16 bytes from nonpaged pool - nothing suita ble found, returning NULL KeBugCheck at mm/rmap.c:382 A problem has been detected and ReactOS has been shut down to prevent damage to your computer.
The bug code is undefined. Please use an existing code instead.
Technical information:
*** STOP: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000)
Frames: <ntoskrnl.exe:dbe3 (ke/bug.c:459 (KeBugCheckEx))> <ntoskrnl.exe:dc03 (ke/bug.c:479 (KeBugCheck))> <ntoskrnl.exe:87911 (mm/rmap.c:382 (MmInsertRmap))> <ntoskrnl.exe:740aa (mm/anonmem.c:385 (MmNotPresentFaultVirtualMemory))> <ntoskrnl.exe:7e8f8 (mm/mm.c:387 (MmNotPresentFault))> <ntoskrnl.exe:befc (mm/i386/pfault.c:66 (MmPageFault))> <ntoskrnl.exe:1927 (ke/i386/exp.c:543 (KiTrapHandler))> <ntoskrnl.exe:399d (/tmp/ccc7YZmh.s:235 (KiTrapProlog))> <ntdll.dll:24118 (/tmp/ccuotceE.s:35 (memset))>
Entered debugger on embedded INT3 at 0x0008:0x800064be. kdb:>
Lock up no keyboard! _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev