none
Why FileStream.Length alloc memory? RRS feed

  • Question

  • When i run my .net2.0 application on my  xp+sp2 pc, i find something amusing me. I read file use code list below:
    using(FileStream stream = new FileStream(...))
    {
    byte[] buf=new byte[stream.length];
    stream.Read(buf, 0, buf.Length);
    }
    I find about 30MB(My file is about 140MB) memory alloc here in stream.length, the stack list below:
    0249dbe0 7c809a69 kernel32!VirtualAlloc+0x18, calling kernel32!VirtualAllocEx
    0249dbfc 79e74449 mscorwks!EEVirtualAlloc+0x104, calling kernel32!VirtualAlloc
    0249dc3c 79e743fa mscorwks!CExecutionEngine::ClrVirtualAlloc+0x15, calling mscorwks!EEVirtualAlloc
    0249dc50 79e74418 mscorwks!ClrVirtualAlloc+0x1b
    0249dc68 7a0bf14b mscorwks!WKS::gc_heap::grow_brick_card_tables+0x138, calling mscorwks!ClrVirtualAlloc
    0249dce8 7a0c0afa mscorwks!WKS::gc_heap::get_segment+0x70, calling mscorwks!WKS::gc_heap::grow_brick_card_tables
    0249dd00 7a0c0c87 mscorwks!WKS::gc_heap::get_large_segment+0x133, calling mscorwks!WKS::gc_heap::get_segment
    0249dd1c 79f2720e mscorwks!Thread:: SysResumeFromGC+0x16e, calling mscorwks!_EH_epilog3
    0249dd38 79f8f6ff mscorwks!IJitManager::IsCacheCleanupRequired+0xf
    0249dd40 79ea2d6e mscorwks!ExecutionManager::IsCacheCleanupRequired+0x10, calling mscorwks!IJitManager::IsCacheCleanupRequired
    0249dd48 79ea2d20 mscorwks!Thread::HaveExtraWorkForFinalizer+0x3f, calling mscorwks!CExecutionEngine::HasDetachedTlsInfo
    0249dd50 79f250e6 mscorwks!WKS::GCHeap::GarbageCollectGeneration+0x361, calling mscorwks!Thread::HaveExtraWorkForFinalizer
    0249dd70 79f24ef2 mscorwks!WKS::gc_heap::try_allocate_more_space+0x1a0, calling mscorwks!WKS::GCHeap::GarbageCollectGeneration
    0249dd74 7a0c2a17 mscorwks!WKS::gc_heap::try_allocate_more_space+0x559, calling mscorwks!WKS::gc_heap::get_large_segment
    0249ddb4 79e98ad1 mscorwks!AcquireSafeHandle+0x35, calling mscorwks!_EH_epilog3
    0249ddd0 79e7dcdf mscorwks!StackingAllocator::Collapse+0x1c, calling mscorwks!StackingAllocator::Clear
    0249ddf8 79e74f4f mscorwks!WKS::gc_heap::allocate_more_space+0x18, calling mscorwks!WKS::gc_heap::try_allocate_more_space
    0249de14 79eaaed9 mscorwks!WKS::gc_heap::allocate_large_object+0x82, calling mscorwks!WKS::gc_heap::allocate_more_space
    0249de4c 7a0c2d24 mscorwks!WKS::GCHeap::Alloc+0xc6, calling mscorwks!WKS::gc_heap::allocate_large_object
    0249de68 79e74cc2 mscorwks!Alloc+0x72
    0249de7c 79e956a2 mscorwks!FastAllocatePrimitiveArray+0xbd, calling mscorwks!Alloc
    0249de98 79e98af0 mscorwks!SafeHandle::AddRef+0x18, calling kernel32!InterlockedCompareExchange
    0249dea4 79e74e5c mscorwks!HelperMethodFrame::LazyInit+0x17, calling  (JitHelp: CORINFO_HELP_GET_THREAD)
    0249deac 79e74e3f mscorwks!HelperMethodFrame::HelperMethodFrame+0x1d, calling mscorwks!HelperMethodFrame::LazyInit
    0249ded0 79e95702 mscorwks!JIT_NewArr1+0x148, calling mscorwks!FastAllocatePrimitiveArray
    0249df20 79e8f349 mscorwks!JIT_NewArr1+0x22, calling mscorwks!LazyMachStateCaptureState
    0249df58 79378581 (MethodDesc 0x792496f0 +0x3d System.IO.FileStream.get_Length()), calling 79680414

    what does this mean? Why  alloc  occurs in FileStream.get_Length()? And when i use !eeheap -gc , i cannot see such address about 30MB , why?
    Friday, April 18, 2008 5:17 AM

All replies

  • The stack trace clear shows it is the new byte[] code being executed.  The last managed code that executed was the get_Length() property getter.  Such a large array gets allocated in the Large Object Heap, that's not a garbage collected heap.  Not sure where you got 30MB, perhaps that how much memory was allocated in the GC heaps?  It is the LOH were you should be able to find it back.
    Friday, April 18, 2008 6:05 PM
    Moderator
  • !eeheap -gc will show LOH , ans there no such address list by !eeheap.  My file is 140MB, so array  will be 140MB ,not 30MB. I check this by view the  virtualalloc args, and after this virtualalloc i can see this 30MB memory by use !address in windbg. So i think it not such array make memory alloc, it is something else.
    Saturday, April 19, 2008 10:44 AM
  • To troubleshoot this issue, we really need the source code and the detailed repro steps to reproduce the problem, so that we can investigate the issue in house. It is not necessary that you send out the complete source of your project. We just need a simplest sample to reproduce the problem. You can remove any confidential information or business logic from it.


    You can send a sample project and repro steps in details to my email address which can be found in my personal profile page.

    Monday, April 21, 2008 3:35 AM
  • I hope i can do what u want me do . But my application is huge one , i cannot reproduce it simple yet . Can u give me some directions about such problem?  I wonder if it cause by lots of objects alloced in GC heap . !dumpheap show me threre are 205225 objects in GC heap.

    Monday, April 21, 2008 5:37 AM