Memory leaks while calling functions from another assembly.
-
Hi all, In our application, we need to call functions from external assembly. Below is what we have already done? 1 Please note that user can create his own assemblies and can call any static public functions in those assemblies from our application. 2 Once the user has created his assembly, he let our application know which function in that assembly is to be called. 3 We load user specified assembly in a separate application domain. 4 We determine if the function that user wants to execute, actually exists in that assembly. (For this we use reflection to get complete information of the assembly). 5 Then we create parameters that are to be passed to the function in external assembly. For preparing parameters we are using a class Arg derived from interface MarshalByRefObject as below:
internal abstract class Arg : MarshalByRefObject
{
...
}So Arg's object will represent parameters to be passed. 6 Now the problem comes. More the parameter we pass to a function in external assembly, more the memory leaks are there. If we call a function several times, memory leaks grows proportionally (even when that separate app-domain is unloaded). 7 So the reason of these memory leaks is that parameters (represented by Arg class derived from MarshalByRefObject) are not being collected by Garbage Collector (even when called explicitly). 8 Any comment on how can we free objects of Arg (created for passing parameters)? Or is there something that we should take extreme care about while doing stuff like this? Regards Aseem
-
Hi all, In our application, we need to call functions from external assembly. Below is what we have already done? 1 Please note that user can create his own assemblies and can call any static public functions in those assemblies from our application. 2 Once the user has created his assembly, he let our application know which function in that assembly is to be called. 3 We load user specified assembly in a separate application domain. 4 We determine if the function that user wants to execute, actually exists in that assembly. (For this we use reflection to get complete information of the assembly). 5 Then we create parameters that are to be passed to the function in external assembly. For preparing parameters we are using a class Arg derived from interface MarshalByRefObject as below:
internal abstract class Arg : MarshalByRefObject
{
...
}So Arg's object will represent parameters to be passed. 6 Now the problem comes. More the parameter we pass to a function in external assembly, more the memory leaks are there. If we call a function several times, memory leaks grows proportionally (even when that separate app-domain is unloaded). 7 So the reason of these memory leaks is that parameters (represented by Arg class derived from MarshalByRefObject) are not being collected by Garbage Collector (even when called explicitly). 8 Any comment on how can we free objects of Arg (created for passing parameters)? Or is there something that we should take extreme care about while doing stuff like this? Regards Aseem
when objects are no longer required yet fail to get collected, the most common cause is you still are referencing them somehow. Maybe you have a collection of Arg instances somewhere, which is growing all the time? A simple Clear() could fix that. Remember, a static class is loaded and initialized on its first use and never relinquished. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
when objects are no longer required yet fail to get collected, the most common cause is you still are referencing them somehow. Maybe you have a collection of Arg instances somewhere, which is growing all the time? A simple Clear() could fix that. Remember, a static class is loaded and initialized on its first use and never relinquished. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
The objects that we are creating are purely local to a function. And we don't have even a single global/static variable. So the reason is something else. I guess it has something to do with either Application-Domain or MarshalByRefObject. Something we should take care about them which we are not doing.
-
The objects that we are creating are purely local to a function. And we don't have even a single global/static variable. So the reason is something else. I guess it has something to do with either Application-Domain or MarshalByRefObject. Something we should take care about them which we are not doing.
People may need to see the relevant code, in order to help you out. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
People may need to see the relevant code, in order to help you out. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
I am sorry, I am not authorized to share the code. Also I cannot produce similar sample of code. Its too big and complex to understand. And I myself have just 1 month of experience in .Net. This problem is very specific. Someone if know the things to be taken care about Application-Domain and MarshalByRefObject while calling functions from external assembly? As objects derived from MarshalByRefObject are not getting collected by Garbage Collector, there could be some special way of freeing them from memory.
-
Hi all, In our application, we need to call functions from external assembly. Below is what we have already done? 1 Please note that user can create his own assemblies and can call any static public functions in those assemblies from our application. 2 Once the user has created his assembly, he let our application know which function in that assembly is to be called. 3 We load user specified assembly in a separate application domain. 4 We determine if the function that user wants to execute, actually exists in that assembly. (For this we use reflection to get complete information of the assembly). 5 Then we create parameters that are to be passed to the function in external assembly. For preparing parameters we are using a class Arg derived from interface MarshalByRefObject as below:
internal abstract class Arg : MarshalByRefObject
{
...
}So Arg's object will represent parameters to be passed. 6 Now the problem comes. More the parameter we pass to a function in external assembly, more the memory leaks are there. If we call a function several times, memory leaks grows proportionally (even when that separate app-domain is unloaded). 7 So the reason of these memory leaks is that parameters (represented by Arg class derived from MarshalByRefObject) are not being collected by Garbage Collector (even when called explicitly). 8 Any comment on how can we free objects of Arg (created for passing parameters)? Or is there something that we should take extreme care about while doing stuff like this? Regards Aseem
I would see stuff like this when I was using mixed (managed C++) code. What I found was that the references to the called DLLs were not being released unless I unloaded them by hand. So, what you might try is loading the DLLs dynamically in your C# app, then unloading them and setting their references to null when finished using them. Each time a DLL function is called, you might then reload the DLL, but this might help you get rid of your memory leak.
-
I would see stuff like this when I was using mixed (managed C++) code. What I found was that the references to the called DLLs were not being released unless I unloaded them by hand. So, what you might try is loading the DLLs dynamically in your C# app, then unloading them and setting their references to null when finished using them. Each time a DLL function is called, you might then reload the DLL, but this might help you get rid of your memory leak.
Once an assembly (a .Net dll) is loaded, it cannot be unloaded and so it will remain in application's address space until process's life time. To avoid this we should load an assembly in a separate application domain. An application domain can be unloaded whenever we want and while it unloads, it also unload all assemblies loaded inside it. So problem can not be resolved as you said. But yes, as you said we have mixed code of Unmanaged C++, Managed C++ and C#. Could this mix of code have any implication?
-
I am sorry, I am not authorized to share the code. Also I cannot produce similar sample of code. Its too big and complex to understand. And I myself have just 1 month of experience in .Net. This problem is very specific. Someone if know the things to be taken care about Application-Domain and MarshalByRefObject while calling functions from external assembly? As objects derived from MarshalByRefObject are not getting collected by Garbage Collector, there could be some special way of freeing them from memory.
-
I am sorry, I am not authorized to share the code. Also I cannot produce similar sample of code. Its too big and complex to understand. And I myself have just 1 month of experience in .Net. This problem is very specific. Someone if know the things to be taken care about Application-Domain and MarshalByRefObject while calling functions from external assembly? As objects derived from MarshalByRefObject are not getting collected by Garbage Collector, there could be some special way of freeing them from memory.
Seems I was unaware of the potential problems with MarshalByRefObject. Here[^] is another article you may want to read. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
Hi all, In our application, we need to call functions from external assembly. Below is what we have already done? 1 Please note that user can create his own assemblies and can call any static public functions in those assemblies from our application. 2 Once the user has created his assembly, he let our application know which function in that assembly is to be called. 3 We load user specified assembly in a separate application domain. 4 We determine if the function that user wants to execute, actually exists in that assembly. (For this we use reflection to get complete information of the assembly). 5 Then we create parameters that are to be passed to the function in external assembly. For preparing parameters we are using a class Arg derived from interface MarshalByRefObject as below:
internal abstract class Arg : MarshalByRefObject
{
...
}So Arg's object will represent parameters to be passed. 6 Now the problem comes. More the parameter we pass to a function in external assembly, more the memory leaks are there. If we call a function several times, memory leaks grows proportionally (even when that separate app-domain is unloaded). 7 So the reason of these memory leaks is that parameters (represented by Arg class derived from MarshalByRefObject) are not being collected by Garbage Collector (even when called explicitly). 8 Any comment on how can we free objects of Arg (created for passing parameters)? Or is there something that we should take extreme care about while doing stuff like this? Regards Aseem
To be 100% sure what the problem is, crack out windbg with the SOS extension for .Net. You can use ADPlus to take a memory dump of the .Net process in question, and then load the dump file into windbg. The SOS debugger extension is used for debugging .Net memory dumps. Using !dumpheap -stat will show you all instances of objects on the heap. Given an instance handle, using !gcroot will tell you which thread is keeping the instance alive. Using !clrstack for that thread will show you the stack for that thread, pin pointing the exact code. These commands are only the tip of the iceberg though, check out Tess Fernandez's blog at http://blogs.msdn.com/b/tess/[^] for help on using windbg for memory leak debugging in .Net.