small, slow memory leak
-
is the most annoying bug to address. I think I may lose my mind today. I've never written an application that suffered from one, and I've written numerous applications similar to this current one. I fear it may be due to my interaction with a legacy set of libraries.
Visual Studio Profiler cannot do the job for you? I mean, to track where the memory is used.
-
I worked on an application that puts together huge download files from a database. Even the delay caused by the garbage collection may be too much. First, look that you implement (and use) Dispose() on all relevant large data objects. Without having to wait for garbage collection the real behavior of your application gets much clearer to see. And if there really is a leak, then look out for objects which hold references to each other or in a circle. Those would survive garbage collection, so it would be better to set all references to other objects to null whuile disposing them. We had a tricky situation in an ASP .Net app, where some fool stored controls in the session state. The page held references to the controls, the controls held references to the page. They were never released by the garbage collection and memory got fuller with every page request.
"I have what could be described as the most wide-open sense of humor on the site, and if I don't think something is funny, then it really isn't." - JSOC, 2011 -----
"Friar Modest never was a prior" - Italian proverb"We had a tricky situation in an ASP .Net app, where some fool stored controls in the session state." Do you work for the SQL Server SSRS team? They store everything they can possibly come up with session state (or the cache depending on how you configure it). 1.2GB in 2min? No problemo.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
"We had a tricky situation in an ASP .Net app, where some fool stored controls in the session state." Do you work for the SQL Server SSRS team? They store everything they can possibly come up with session state (or the cache depending on how you configure it). 1.2GB in 2min? No problemo.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
Not that I know of, but perhaps they made me drunk and dragged me aboard last night :) At least sailors where once recruited that way.
"I have what could be described as the most wide-open sense of humor on the site, and if I don't think something is funny, then it really isn't." - JSOC, 2011 -----
"Friar Modest never was a prior" - Italian proverb -
is the most annoying bug to address. I think I may lose my mind today. I've never written an application that suffered from one, and I've written numerous applications similar to this current one. I fear it may be due to my interaction with a legacy set of libraries.
Hi, I've got no idea what could cause your C# memory leak. But you may want to have a look at this blog entry considering the dangers of the large object heap. It is about how allocating alternate big lumps of memory and smaller lumps then freeing the bigger lump to allocating a slightly bigger lump repeatedly may lead to memory loss. http://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/[^] It took me a long time to find this error and as it happens when adding stuff to lists in a quite simple way it could happen to you! Good luck. Erik
-
is the most annoying bug to address. I think I may lose my mind today. I've never written an application that suffered from one, and I've written numerous applications similar to this current one. I fear it may be due to my interaction with a legacy set of libraries.
I hate those. A couple years ago I had a GDI resource leak (caused by a leaked MFC object) that only showed up after my application had been running a week or more. It took months to find that one.
Software Zen:
delete this; -
I hate those. A couple years ago I had a GDI resource leak (caused by a leaked MFC object) that only showed up after my application had been running a week or more. It took months to find that one.
Software Zen:
delete this;I'd say resource leaks are one kind of the two most likely causes of memory leaks in managed code. The other would be using static collections. But resource held by any object would be released by finaliser after GC - so unless one uses a buggy library, it can only be a result of using unmanaged code without implementing proper finaliser. So I would start by searching for "static" in the code.
-
I'd say resource leaks are one kind of the two most likely causes of memory leaks in managed code. The other would be using static collections. But resource held by any object would be released by finaliser after GC - so unless one uses a buggy library, it can only be a result of using unmanaged code without implementing proper finaliser. So I would start by searching for "static" in the code.
In this case, it was a native-mode application (no GC, no finalizer, etc.). One of our test technicians found a sequence of actions that made the problem happen more likely to occur: in a couple of hours, rather than several days. That eventually let me track it down and fix it.
Software Zen:
delete this; -
is the most annoying bug to address. I think I may lose my mind today. I've never written an application that suffered from one, and I've written numerous applications similar to this current one. I fear it may be due to my interaction with a legacy set of libraries.
You can track down the memory leak using the Signal Flare debugging pattern: Increase the size of your objects (one at a time) 50-fold, and rerun your program. When the memory leak jumps 50-fold, you've found your problem.
-
is the most annoying bug to address. I think I may lose my mind today. I've never written an application that suffered from one, and I've written numerous applications similar to this current one. I fear it may be due to my interaction with a legacy set of libraries.
Hello, This might not be applicable in your particular scenario, and there are performance issues that should be accounted for (starting an exe is relatively slow), but I have dealt with leaky third-party libraries I can't circumvent by wrapping their use on a different executable file. Instead of directly linking the library to my application, I execute the wrapper process and pass the parameters on the command line. The thing is that *all* resources are freed once the wrapper process dies. You could improve performance by creating a service-like app (probably using WCF) that is restarted once a memory usage threshold is exceeded. This might be a little harder to code but avoids the performance penalty incurred when a process starts. This should only be considered as a last option. Hope this might help, and good luck! :cool: Sergio
-
is the most annoying bug to address. I think I may lose my mind today. I've never written an application that suffered from one, and I've written numerous applications similar to this current one. I fear it may be due to my interaction with a legacy set of libraries.
"small and slow" are definitely annoying. Sometimes the big ones can be fun, though. I have a side-project which consists of many parts. They all centre around this GDI based display (like a custom powerpoint) and originally I planned to draw to a buffer (Bitmap) from a separate thread and the display would read from that buffer. For performance, there were two buffers and they swapped. Unfortunately I forgot about the whole de-allocation thing and on a 1024x768 display it leaked memory at 50MB/s.
Ninja (the Nerd)
Confused? You will be... -
That is no fun. Do you have to fully restart, or can you clean it up, sort of reinitialize? I have had coworkers do similar things to get things by and into beta. Restarting weekly. (in my industry nothing happens on Saturdays, ever) I also just realized this issue only happens on the production server facing the production database. Running it on my corporate dev box, against the dev database produces level memory. It is subscribed to the exact same feed of live data. The prod server is running Windows Server SP1 and my desktop is running Windows 7. I've also seen an allusive error on the prod box that has never happened on my corporate box running the same program simultaneously.
-
is the most annoying bug to address. I think I may lose my mind today. I've never written an application that suffered from one, and I've written numerous applications similar to this current one. I fear it may be due to my interaction with a legacy set of libraries.
As well as the suggestions from others, look out for objects (including controls etc) referencing each other via events (connecting to an event handler is normally a strong reference unless you deliberately code it as a weak one). This is particularly bad for events on static objects (some of these exist in the Windows Forms libraries for example, for detecting session/colour depth/resolutions changes etc).