Hunting Down Memory Leaks...?
-
Max_Power_Up wrote:
so Im not spending money on a tool to find a leak
So do it the old-fashioned way. Restructure the program so that it does nothing at all, and see if it still leaks. Then add in functionality back in bit by bit until it starts leaking. The bit you just added in is the leaky bit. Also, don't rule out memory leaks in the Windows API itself. There are a few of those lurking around.
I just spent an hour staring at Task Manager Extended written by Zoltan Csizmadia , really great app , and I checked the Handle count, the thread count, the IO Read/Write Read Bytes , Write Bytes , and User and GDI Objects , all of which remains stable while the Memory grows - from 2,804Kb to 3,016Kb within about 90 seconds, which explains why it kills the pc after a few hours - rapid growth... I also noticed that my Page Fault count kept increasing the moment a leak occured - from 824 (kind of normal - i think?) to 833 with everything else staying the same. The program itself occludes your screen - its a screen "protector" which hides any useful data that might be on your screen from unwanted users while you take a stroll in the park - which is why its kind of hard to start from the bottom up - because it doesn't do anything, but it also wont work at all unless it does everything at once - you see the problem? I have been searching through the CodeProject Article base and have found a tool called MemoryHooks UI , which does report that there is a leak in the program - but does not report where it is ... So I guess its back to square one..:doh: Thanks for all the suggestions guys - keep them coming...:cool:
The tears shed in vain and the hatred and pain will be nothing but dust at the end of the day
-
I forgot to mention - its not a malloc / free memory leak , its definitely sopmething else - I've used the ninth-sense-find-dialog-of-memory-leak-doom and I've plugged my ears and shut my eyes.... all to no avail - my program just keeps on using more and more memory - its probably a GDI problem, but even there on that front I have done everything exactly as it should be done - every SelectObject is caught and deleted, and every brush is deselected and destroyed, and yet the problem persists - my program (while running) keeps taking up more and more memory - and eventually , uses up all the available memory in the system, the leak is so small that it takes hours to destroy the system and I've used other malloc / free replacing solutions - thats how I discovered that every malloc has a free in my code. So any other suggestions would be great - its plain C and its my own hobby code - its GPL code - so Im not spending money on a tool to find a leak - and also I tried there is only this new .net leak detector on the internet - which is silly because I cant use it to profile C code... So if anybody has a C-specific suggestion, at would be appreciated...:confused:
The tears shed in vain and the hatred and pain will be nothing but dust at the end of the day
You have a problem with the way you view this task. You say you have checked everything and there is nothing wrong. You say your program leaks memory. Those two statements cannot both be true. It seems clear that the second is true so you must abandon your belief in the first. It should be fairly easy to determine whether the leak is GDI or heap. Then, without the help of fancy tools, you just have to employ good old-fashioned determination and grit. Remember: when real programmers started programming in C that's all there was! Happy hunting!
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
-
You have a problem with the way you view this task. You say you have checked everything and there is nothing wrong. You say your program leaks memory. Those two statements cannot both be true. It seems clear that the second is true so you must abandon your belief in the first. It should be fairly easy to determine whether the leak is GDI or heap. Then, without the help of fancy tools, you just have to employ good old-fashioned determination and grit. Remember: when real programmers started programming in C that's all there was! Happy hunting!
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
I believe you - after all, there HAS to be something wrong... I would've immediately blamed it on a GDI leak, but I have examined the GDI Ojects column in Task Manager Extended and Im fairly satisfied that the code and the program do not leak HBITMAPs or HBRUSHes or anything of that sort, so my initial belief that it was a malloc|free misnomer was wrong, since I have used some tools - after first using the Mighty-Find-Dialog-Of-Memory-Leak-Demise , and satisfying meself once and for all that my malloc|free method of coding is working (I write the two lines of code ie:malloc(...)free(...) and then fill in the actual code in BETWEEN the two calls) which helps me to _avoid_ memory leaks before my memory fails and I cause them myself. Its the same with GDI objects as well, _everywhere_ in my code you will see things like :
HGDIOBJ old = SelectObject(...); //... //... SelectObject(...,old);or even more efficiently ://... DeleteObject(SelectObject(HDC,OBJECT)); //...which actually helps you to avoid leaking memory _BEFORE_ it leaks, so I have my code written in this beautiful format and Im still suffering from an inexplicable leak... Well, such is life, I will try to take a peak at the heap when I get a chance to take a lunch break later...The tears shed in vain and the hatred and pain will be nothing but dust at the end of the day
-
Hi there everybody, has anybody ever had to track a memory leak in a C program? I know this sounds strange, because there are alot more *advanced* languages out there so _nobody_ would still be using C right? Wrong.... I still use C to accomplish alot of the really useful things that are only useful if they can be done quickly and require very little overhead - no wasted space for garbage collection and exception handling and runtime type checking and polymorphism and all that jazz... So, I have come accross a very strange bug :doh: that I've *never* come across before - seeing as how I've been coding in C for a good couple of years now, I've generally developed a leak- seventh-sense (the sixth is currently occupied with telepathically sensing when a hyped-up middle manager is in the vicinity so I can dodge him) ... So, If there are any of you Die-Hard-With-Many-Vengeances C coders out there, then drop me a line and let me know what tools you use to track bugs that you cant see - even though C gives you Bug-Ray vision...:cool: I use the PellesC compiler - Having been converted from LCCWin32 Compiler (for the lack of a "copy" | "paste" command on the context menu ) and I generally don't ever need any extra tools besides the built-in debugger...
The tears shed in vain and the hatred and pain will be nothing but dust at the end of the day
We use Memory Validator[^] for this...it also detects handle leaks, which are equally annoying when they occur. Highly recommended. :beer:
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
We use Memory Validator[^] for this...it also detects handle leaks, which are equally annoying when they occur. Highly recommended. :beer:
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
Its huge... Im not exactly a fan of downloading large files to do small jobs - and apparently it only works with the .net runtime - in case it hasn't been made clear - Im using C code. I don't ever work with .net its like asking a paralyzed guy for a 'high five',its just not cool. Well, I will try to download it when I get the chance - and the bandwidth - thanks.
The tears shed in vain and the hatred and pain will be nothing but dust at the end of the day
-
Its huge... Im not exactly a fan of downloading large files to do small jobs - and apparently it only works with the .net runtime - in case it hasn't been made clear - Im using C code. I don't ever work with .net its like asking a paralyzed guy for a 'high five',its just not cool. Well, I will try to download it when I get the chance - and the bandwidth - thanks.
The tears shed in vain and the hatred and pain will be nothing but dust at the end of the day
Neither do we. Our code is entirely native C++ (written in VS2003 using WTL), and Memory Validator works just fine with it. :) As far as size goes, the last time I looked (v4.46) it was 17MB, which I'd hardly call huge. Believe me Boundschecker is far larger (and more expensive to boot)! The alternative is printf debugging or some form of static code analysis (PC-Lint for example catches some types of memory leaks, but that's not its main purpose so I wouldn't recommend it specifically for such a task).
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
Hi there everybody, has anybody ever had to track a memory leak in a C program? I know this sounds strange, because there are alot more *advanced* languages out there so _nobody_ would still be using C right? Wrong.... I still use C to accomplish alot of the really useful things that are only useful if they can be done quickly and require very little overhead - no wasted space for garbage collection and exception handling and runtime type checking and polymorphism and all that jazz... So, I have come accross a very strange bug :doh: that I've *never* come across before - seeing as how I've been coding in C for a good couple of years now, I've generally developed a leak- seventh-sense (the sixth is currently occupied with telepathically sensing when a hyped-up middle manager is in the vicinity so I can dodge him) ... So, If there are any of you Die-Hard-With-Many-Vengeances C coders out there, then drop me a line and let me know what tools you use to track bugs that you cant see - even though C gives you Bug-Ray vision...:cool: I use the PellesC compiler - Having been converted from LCCWin32 Compiler (for the lack of a "copy" | "paste" command on the context menu ) and I generally don't ever need any extra tools besides the built-in debugger...
The tears shed in vain and the hatred and pain will be nothing but dust at the end of the day
Max_Power_Up wrote:
has anybody ever had to track a memory leak in a C program?
yes. and squash them like a pumpkin.
Max_Power_Up wrote:
I have come accross a very strange bug
Although all bugs are generally programming errors, I have never been one to consider a memory leak a "bug" it is definately a huge programming error, and should not be left as a "small thing" use the tools to find it, find them soon, find them fast, verify often. In some cases you can remove the tools before distribution, but you want most of your internal checks, and all of your desk checks to include the proper tools. I wrote my own, but here[^] are some more, and listen to Anna, she's making more sense than you, a memory leak is NOT a small problem, don't treat it like one.
Max_Power_Up wrote:
and I generally don't ever need any extra tools besides the built-in debugger...
obviously... :rolleyes:
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Max_Power_Up wrote:
has anybody ever had to track a memory leak in a C program?
yes. and squash them like a pumpkin.
Max_Power_Up wrote:
I have come accross a very strange bug
Although all bugs are generally programming errors, I have never been one to consider a memory leak a "bug" it is definately a huge programming error, and should not be left as a "small thing" use the tools to find it, find them soon, find them fast, verify often. In some cases you can remove the tools before distribution, but you want most of your internal checks, and all of your desk checks to include the proper tools. I wrote my own, but here[^] are some more, and listen to Anna, she's making more sense than you, a memory leak is NOT a small problem, don't treat it like one.
Max_Power_Up wrote:
and I generally don't ever need any extra tools besides the built-in debugger...
obviously... :rolleyes:
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
El Corazon wrote:
a memory leak is NOT a small problem, don't treat it like one.
Yeah. Never had a major problem like that in any of my stuff (thank cthulu) but a few years ago I got into a brawl with a bunch of fanboi's on a game forum (galciv2????) when a change the dev team made to the memory model resulted in a relatively slow leak. Went from 500meg to 2gig after being open/played for a week. The fanboi's were all like 'stfu just restart teh gamz0r j00 n00b'. Thankfully after a week or so the devs mea cuplaed publicly and fully agreed it was a major needs fixed problem. :)
-- If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
-
I believe you - after all, there HAS to be something wrong... I would've immediately blamed it on a GDI leak, but I have examined the GDI Ojects column in Task Manager Extended and Im fairly satisfied that the code and the program do not leak HBITMAPs or HBRUSHes or anything of that sort, so my initial belief that it was a malloc|free misnomer was wrong, since I have used some tools - after first using the Mighty-Find-Dialog-Of-Memory-Leak-Demise , and satisfying meself once and for all that my malloc|free method of coding is working (I write the two lines of code ie:malloc(...)free(...) and then fill in the actual code in BETWEEN the two calls) which helps me to _avoid_ memory leaks before my memory fails and I cause them myself. Its the same with GDI objects as well, _everywhere_ in my code you will see things like :
HGDIOBJ old = SelectObject(...); //... //... SelectObject(...,old);or even more efficiently ://... DeleteObject(SelectObject(HDC,OBJECT)); //...which actually helps you to avoid leaking memory _BEFORE_ it leaks, so I have my code written in this beautiful format and Im still suffering from an inexplicable leak... Well, such is life, I will try to take a peak at the heap when I get a chance to take a lunch break later...The tears shed in vain and the hatred and pain will be nothing but dust at the end of the day
It's sensible to code as you do, putting in the
freeat the same time as themallocand so on, BUT IT DOES NOTHING TO GUARANTEE LEAK-FREE CODE! You still have to ensure (for example) that themalloccan only occur once and that program flow cannot leave the function without hitting thefree. It's your blindness to the fact that something IS wrong that stops you seeing it.Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
-
Hi there everybody, has anybody ever had to track a memory leak in a C program? I know this sounds strange, because there are alot more *advanced* languages out there so _nobody_ would still be using C right? Wrong.... I still use C to accomplish alot of the really useful things that are only useful if they can be done quickly and require very little overhead - no wasted space for garbage collection and exception handling and runtime type checking and polymorphism and all that jazz... So, I have come accross a very strange bug :doh: that I've *never* come across before - seeing as how I've been coding in C for a good couple of years now, I've generally developed a leak- seventh-sense (the sixth is currently occupied with telepathically sensing when a hyped-up middle manager is in the vicinity so I can dodge him) ... So, If there are any of you Die-Hard-With-Many-Vengeances C coders out there, then drop me a line and let me know what tools you use to track bugs that you cant see - even though C gives you Bug-Ray vision...:cool: I use the PellesC compiler - Having been converted from LCCWin32 Compiler (for the lack of a "copy" | "paste" command on the context menu ) and I generally don't ever need any extra tools besides the built-in debugger...
The tears shed in vain and the hatred and pain will be nothing but dust at the end of the day
If you were using VC you could use the function _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); , included via , MSDN explains what it does. It's what I use, and a report of leaked memory appears in visual studio's output window whenever I forget to free memory, as well as a little hint whereabouts it occurred.
-
If you were using VC you could use the function _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); , included via , MSDN explains what it does. It's what I use, and a report of leaked memory appears in visual studio's output window whenever I forget to free memory, as well as a little hint whereabouts it occurred.
Well - like I've said before - its not a malloc|free issue, I have taken great pains to search through the code as you all suggested - I did, and nowhere in the code do I call more mallocs than frees, and nowhere do I allocate memory that cannot be de-allocated *before* a branching instructions occurs - the allocations are all in tiny local functions like ones which manipulate text and so forth - there are no branching instructions anywhere near my mallocs. It - therefore - has to be a GDI leak, that is the only conclusion I can reach from studying the code in this manner. I have gone to great lengths to track down this elusive leak - which I admit - is an error on my part, and still no success - I have even tried the suggested option of removing all the drawing code - which does not even slow the leak down, no, it's somewhere in here with some other code that gets called by some other code which was called by some other code which was called by some other code in my program.... As you can see - its going on two days, and I still haven't gotten any closer to finding my error.... Im considering rewriting this whole program in Java...:laugh:
The tears shed in vain and the hatred and pain will be nothing but dust at the end of the day