Thread Leak
-
I am finding a new kind of memory link. Maybe not new but new to me. I have an application that generates 50 to 70 threads. I am using a vision library by a third part which generates many of them. My program is a C#/WPF. I think the library was done in C++. I capture and analyze an image every 60 msec. After 3 to 4 hours I see the thread count for the application rise. This is well over 100,000 images. Every image creates a few threads and then closes them when finished. This spreads the load out over several core. I am watching it in Resource Monitor. Of course as thread count raises so does memory. Has anyone seen a similar leak?
So many years of programming I have forgotten more languages than I know.
-
I am finding a new kind of memory link. Maybe not new but new to me. I have an application that generates 50 to 70 threads. I am using a vision library by a third part which generates many of them. My program is a C#/WPF. I think the library was done in C++. I capture and analyze an image every 60 msec. After 3 to 4 hours I see the thread count for the application rise. This is well over 100,000 images. Every image creates a few threads and then closes them when finished. This spreads the load out over several core. I am watching it in Resource Monitor. Of course as thread count raises so does memory. Has anyone seen a similar leak?
So many years of programming I have forgotten more languages than I know.
Do not know for sure. But you could try to call Garbage Collection manually after processing an image. Use
GC.WaitForPendingFinalizers()andGC.Collect(). Maybe that helps. -
I am finding a new kind of memory link. Maybe not new but new to me. I have an application that generates 50 to 70 threads. I am using a vision library by a third part which generates many of them. My program is a C#/WPF. I think the library was done in C++. I capture and analyze an image every 60 msec. After 3 to 4 hours I see the thread count for the application rise. This is well over 100,000 images. Every image creates a few threads and then closes them when finished. This spreads the load out over several core. I am watching it in Resource Monitor. Of course as thread count raises so does memory. Has anyone seen a similar leak?
So many years of programming I have forgotten more languages than I know.
It's hard to say. The issue could be inside this external library, or it could be in your code. What I would do is, rather than trying to manage the threading by yourself, make use of the Task Parallel Library (TPL). This is a great way to have your code do threading without burdening you with thread lifetime issues. It's incredibly simple to use.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
Do not know for sure. But you could try to call Garbage Collection manually after processing an image. Use
GC.WaitForPendingFinalizers()andGC.Collect(). Maybe that helps.Even if the system is not used for 5 minutes the extra threads still persists. That should be plenty of time for automatic garbage collection to get rid of old threads.
So many years of programming I have forgotten more languages than I know.
-
It's hard to say. The issue could be inside this external library, or it could be in your code. What I would do is, rather than trying to manage the threading by yourself, make use of the Task Parallel Library (TPL). This is a great way to have your code do threading without burdening you with thread lifetime issues. It's incredibly simple to use.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierI am fairly sure it is inside the external library. It processes the images and create all the threads. I only provide an operator interface and process the results.
So many years of programming I have forgotten more languages than I know.
-
I am fairly sure it is inside the external library. It processes the images and create all the threads. I only provide an operator interface and process the results.
So many years of programming I have forgotten more languages than I know.
If it's in that library then you have no recourse but to notify the vendor that their library is leaking memory.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
If it's in that library then you have no recourse but to notify the vendor that their library is leaking memory.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierI have gone to the vendor. Since it takes hours and several 100,000 images they cannot reproduce it and cannot deal with it. It is kind of an exponential failure. Once you get one then there is a higher probability of getting the second, etc. I do not expect a fix at this point but still hope. It is just a very different kind of bug than I have ever seen and in so many different ways. I was kind of hoping that someone else had seen something like this and might have some clues because it would be really nice to fix.
So many years of programming I have forgotten more languages than I know.
-
I have gone to the vendor. Since it takes hours and several 100,000 images they cannot reproduce it and cannot deal with it. It is kind of an exponential failure. Once you get one then there is a higher probability of getting the second, etc. I do not expect a fix at this point but still hope. It is just a very different kind of bug than I have ever seen and in so many different ways. I was kind of hoping that someone else had seen something like this and might have some clues because it would be really nice to fix.
So many years of programming I have forgotten more languages than I know.
The only way to fix it is to get the source for the component you're using (yeah, right) and rework the component or scrap the component you're using and use a different library that does the same job, or work up a component from scratch yourself.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
I have gone to the vendor. Since it takes hours and several 100,000 images they cannot reproduce it and cannot deal with it. It is kind of an exponential failure. Once you get one then there is a higher probability of getting the second, etc. I do not expect a fix at this point but still hope. It is just a very different kind of bug than I have ever seen and in so many different ways. I was kind of hoping that someone else had seen something like this and might have some clues because it would be really nice to fix.
So many years of programming I have forgotten more languages than I know.
There's no magic bullet to fix threading issues. You can't try and arbitrarily kill threads because you have no idea as to whether or not they are busy. The problem is, doing threading right is hard - very, very hard. I wouldn't accept their answer that they can't reproduce it - if necessary, you could send them a slimmed down version of your code that triggers the leak and let them use that with their debuggers.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
I am finding a new kind of memory link. Maybe not new but new to me. I have an application that generates 50 to 70 threads. I am using a vision library by a third part which generates many of them. My program is a C#/WPF. I think the library was done in C++. I capture and analyze an image every 60 msec. After 3 to 4 hours I see the thread count for the application rise. This is well over 100,000 images. Every image creates a few threads and then closes them when finished. This spreads the load out over several core. I am watching it in Resource Monitor. Of course as thread count raises so does memory. Has anyone seen a similar leak?
So many years of programming I have forgotten more languages than I know.
I found the problem. It is a memory leak by design in the TextBox control. There is a feature of this box that allows you to undo a change. By default it is set to infinite. Every time you update the value in the control whether from the keyboard or from the code behind it adds to this buffer. It can be turned off completely by putting a -1 in the number of values to be buffered. This is well documented in MSDN forums but several years old. Finding the right search key that forces it to go back that far is very difficult. This is an old tread of mine I just ran across and forgot to update it when I found the answer. I hope this will help others when they do a search.
So many years of programming I have forgotten more languages than I know.