none
LoaderOptimization::MultiDomain leaks? RRS feed

  • Question

  • I posted this first in the VC++ forum and was told to post it here....it does seem to be a C++-specific issue tho, cuz if I write the same program in C# it does not leak.....soooo anyways....can someone explain to me exactly why this snippet leaks like crazy?

    using namespace System;  
    using namespace System::Reflection;  
    using namespace System::Runtime::Remoting;  
     
    ref class MyType : MarshalByRefObject  
    {  
    };  
     
    [System::LoaderOptimization(System::LoaderOptimization::MultiDomain)]  
    int main(array<System::String ^> ^args)  
    {  
        AppDomainSetup^ ads = gcnew AppDomainSetup();  
        ads->LoaderOptimization = LoaderOptimization::MultiDomain;  
        for(;;)  
        {  
            AppDomain^ ad2 = AppDomain::CreateDomain("blah", nullptr, ads);  
            ad2->CreateInstance(MyType::typeid->Assembly->FullName, MyType::typeid->FullName);  
            AppDomain::Unload(ad2);  
            GC::Collect();  
        }  
        return 0;  
    }  
     

    The leak is in the "Loader Heap" (perfmon) or the "Module Thunk Heap" (windbg).  As far as I can figure out, using the MultiDomain loader optimization causes all the assemblies to be loaded into the system-created "shared" domain,  and then each time a new appdomain requests the assembly it *should* use that same copy of the assembly in the "shared" domain....however, it does not appear to be reusing my .exe assembly or (more alarmingly) msvcm80.  Those 2 appear to be being loaded again on every new appdomain...and since the shared domain is never unloaded my memory usage just keeps growing.  Any help is appreciated...thx

    Thursday, July 31, 2008 2:54 AM

All replies

  • small update....it definatly has something to do with unverifiable code, cuz switching my sample app to /clr:safe makes it behave correctly.  This isn't a solution to my problem tho because my actual application I'm trying to 'fix' is ~300K lines of unverifiable code...
    Thursday, July 31, 2008 3:56 PM