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(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev