• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 420
  • Last Modified:

Eating memory

I have some problem with memory leak. The outcommented code cause the leak.
I suspect that a macro somwhere in the windows.h machinery will cause the memory leak. Not sure!
Pleas help me with the problem.

Regards
Andla


                    safe=GetVariable(arrid,"MoveWindow");//
                    if(safe)
                    {
                    }

                    //THIS EATS MEMORY ????????????
                    //if(safe=GetVariable(arrid,"MoveWindow"))
                    //{
                    //}
0
andla
Asked:
andla
  • 8
  • 4
  • 2
  • +3
1 Solution
 
IainHereCommented:
How do you know that the second method leaks memory, but the first doesn't?  The two portions of code should do exactly the same thing, so I don't see what difference there could be.

Basically, I don't think changing from one to the other will make any difference.  If you're happy with the former, stick with it.  If you still have memory leaks, perhaps you could explain what GetVariable is?
0
 
andlaAuthor Commented:
GetVariable is exactly what is says. It gets a varible called MoveWindow. Find the string MoveWindow and return the data that comes next. The data is returned as a void* pointer so i can cast it to whatever i want.

The faulty code is called many times and is called when a window message drops in from the system. Because the function is called many times i can watch the task manager and se that the first code doesn't consume memory but the second does.

Knowing about this hidden bug and why it does what it does is both intresting and can help me with similar bugs in the future so i would be grateful for help on this.

Regards
Andreas

0
 
ZoppoCommented:
Sorry, andla, but I absoluteley have to agree with lainHere ... if there would be such a difference between
these two codefragments there would be a lot of leaking applications out there.

Maybe you could provide us a little bit more code ... I suspect there's another difference/problem in
your code.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
ikbirCommented:
Hi Anda,
    I do not find any difference in the piece of code you have mentioned.
There must be something else to it.

Consider the two sceniero

case1:

void *safe=GetVariable(arrid,"MoveWindow");//
 if(safe)
 {
 }
if(safe) delete(safe);

case 2:
void *safe = 0;
if(void *safe=GetVariable(arrid,"MoveWindow"); //                                  {
}
if(safe) delete(safe);


Assuming memory is allocated in GetVeriable() the there will be memory leak in the case2. I hope you have got the answer to your question.

Ikbir
0
 
ZoppoCommented:
Hi ikbir: it's not a nice habit to post an answer unless it's clear that it's the correct one ... as soon as one answer is posted the question is moved from the 'Questions awaiting answers' section and most experts
won't take a look at it anymore.
0
 
andlaAuthor Commented:
I'm sorry i don't know what happend.

When I wrote this question I can ensure you that this was exactly what happend. Now yesterday after a restart of the computer both examples eats memory.

Also when I started this question I went through the code and thought that i tested all the 'new' allocation commands in the source code by just setting a breakpoint . That time none was called.

Yesterday I did a breaking code before all 'new' command I could find like this:

if(debug)
  Sleep(0)//Setting breakpoint here
.
...new....
.

So i must have missed a 'new' command somewhere. But don't ask me about why the memory was consumed with the above out commented code. I have experienced strange things with visual studio but nothing beats this. These kind of bugs really scares me. How can I find the bug if it change shape just by restarting the computer. Now maybe I can find it I hope.

Regards
Andla
0
 
AxterCommented:
andla,
If you no longer need this question, please delete it, or award the points to the expert you think desrerves it.
0
 
DanRollinsCommented:
this is absurd.  The function named GetVariable is OBVIOUSLY causing the problem.  Why don't you post that code?  Is that function a COM Object member function wrapper? Is it part of an external DLL?  It might use an STL map template, in which case, there are very specific things to check.  What is it, a secret?

-- Dan
0
 
andlaAuthor Commented:
//DanRollins
I'm afraid that the project has grown large. This function uses subfunctions of my own and these subfunctions uses a large memory handling function of my own.
The strange thing is that i have not succeded in copying the bug to a smaller example. If i do then i don't get the memory leak. I have tested and re-tested in loops to reproduce the bug without success. It seams to be stuck in the project.

Strategy:
What i'm going to do now is replacing the GetVariable function (where the leak is) with one of it's subfunctions one after another. Can you help me with any other strategies like the above ? Please don't suggest an expensive alternative because this is a private project and i can't afford tool like bound checker.

Regards
Andreas
0
 
andlaAuthor Commented:
I don't use COM or any similar tech. It's plain C mixed with a Win32 project.
/Andreas
0
 
DanRollinsCommented:
>>and these subfunctions uses a large memory handling function of my own.

The problem is probably in there.  The more complicated the program, the more likely you are to experience hard-to-find bugs.  Alas, it will not be possible for me or anyone else -- except you -- to locate the source of your leak without source code to examine.

-- Dan
0
 
andlaAuthor Commented:
I should have made a movie clip before restart of computer/msdev because there is no way
 a=func(x);
 if(a){}
and
 if(a=func(x)){};
make any difference. Still this is what happend. Maybe a computer ghost somewhere.

Still i would be happy for some help with any strategies i mention if you still want to help.

/Andreas
0
 
IainHereCommented:
If you're using MFC, it might be worth you checking out the documentation on CMemoryState - it can tell you about all of the memory changes in your program.

CMemoryState oldMemState, newMemState, diffMemState;
oldmemState.Checkpoint();
AfxEnableMemoryTracking(TRUE);

//Do things with your dubious function, that shouldn't alter memory state

newMemState.Checkpoint();
if( diffMemState.Difference( oldMemState, newMemState ) )
{
TRACE( "\nMemory leaked - that function was knacked after all.\n" );          
diffMemState.DumpStatistics();
oldMemState.DumpAllObjectsSince();     //Lists all blocks of memory leaking
}
0
 
andlaAuthor Commented:
//IainHere

Thanks for trying to help.
The bad thing is that the bug is stuck in my program. I mean that if i move the code the problem would probebly go away.
I could maybe add MFC support in the studio settings. Don't know because i have very little experience in MFC.

I have a question about memory watching to you all.
Is there a freeware/shareware tool like task manager but displays process memory space in bytes. All process managers that i have seen displays in Kb. I think it would be a helpful tool if i could se when the process memory change while beeing in the debugger. I could se wich function doesent free memory correctly.
If there is any problem with this approach let me know. I was thinking of maybe the debugger locks any attempt of reading memory space of an process. Don't know.

If you help me with this or help me with a useful
strategy I would be satisfied and happy.

Regards
Andla
0
 
DanRollinsCommented:
You can replace the 'new' function with your own.  This is what MFC does:

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

You need to place this in a header that is common to your entire program so that each use of new will instead call DEBUG_NEW.  Then you need to provide a DEBUG_NEW operator that works excactly like new, but also tracks memory allocations.

There is one area we have not explored, but should.  Maybe the memory leak is an illusion.  In many programs, memory usage rises in large increments for the first few seconds or first few iterations of activity.  Then it levels off.  If you don't know that, you might think that there is a memory leak when there really isn't.

-- Dan
0
 
andlaAuthor Commented:
Thanks for your help and every body else trying to help.

I solved the problem. Sorry that I didn't use your help but I would eventually use your tip here. I have some question though about:

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

The preprocessor finds 'DEBUG_NEW' and replace it with 'new'.
Why use #define anyway ?
I was thinking about maybe to trick the compiler so it would not generate an error ?

TO ALL WHO READS THIS.
I did the following strategy to find my bug.
*Isolate the failing functions and place them where the mother function where. Remove mother functions (use //).

*Scan all 'new' functions called. Store the address allocated in debugview window.

*Se if the address content is changed or set to null where it should be deallocated.

In my case it did not deallocate.

*Locate the address and assign it to a pointer where you can use delete []pointer.

Regards
Andla
0
 
DanRollinsCommented:
>>The preprocessor finds 'DEBUG_NEW' and replace it with 'new'.

You have it backwards.  The idea is that every place that you put new, you end up with DEBUG_NEW.  That way, your custom DEBUG_NEW operator takes action rather than the normal new operator.

-- Dan
0
 
andlaAuthor Commented:
Oops! You are right i got it backwards. Sorry! :-)

I will try to make a test project one day with 'new'.

Regards
Andla
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 8
  • 4
  • 2
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now