Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Memory Leakage

Author
Message
AlexI
19
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Posted: 10th Feb 2009 01:06
Hi,
I just want to know something about memory leakage.

Would this code eventually crash:


or does the test variable replace the existing test variables?

Thanks,
Alex

AlexI
19
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Posted: 10th Feb 2009 01:28
Edit: worked it out
http://msdn.microsoft.com/en-us/library/h6227113(VS.80).aspx

Only if you use "new" will it memory leak

Slayer93
20
Years of Service
User Offline
Joined: 5th Aug 2004
Location: I wish I knew
Posted: 10th Feb 2009 01:41 Edited at: 12th Feb 2009 00:10
Edit: Disregard anything said about crashing because of a stack overflow, I was wrong about that

It should crash, but not because of a memory leak (which occurs from the heap). It would crash from a stack overflow.

Basically all local variables are put onto the stack and any dynamic location is put onto the heap (there is other stuff to but look at the below link). Local variables on the stack are kept until out of scope (the method ends). So if you looped through and kept making a variable it would eventually crash because it would never destroy the variables thus filling the stack up.

This should help you understand how the stack and heap works more - http://www.learncpp.com/cpp-tutorial/79-the-stack-and-the-heap/

Hope that helps

Edit: Seems you found out before I finished typing

AndrewT
17
Years of Service
User Offline
Joined: 11th Feb 2007
Location: MI, USA
Posted: 10th Feb 2009 02:40
If you need to declare a variable in a loop like that you may consider making it static:



The static keyword ensures that the variable only gets declared once.

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 10th Feb 2009 04:30
Slayer - I think you're right 99% but 1% off. (Or I am 100% off - one or the other)

In that simple loop - the variable DOES go out of scope when the end bracket for the while loop is encountered - it should NOT blow up the stack.

--Jason

IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 10th Feb 2009 14:21
Nope, no crash, no stack exhaustion, no nothing. That code is perfectly safe.

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 10th Feb 2009 14:47
This would kill the stack for sure:

function DieYouMSLadenPC(void){
DieYouMSLadenPC();
};

<evil chuckling>

IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 10th Feb 2009 15:07
Actually ...

You'll need to test this, but if you do this in release mode, the compiler may detect the tail-recursion and replace the CALL statement with a JMP instead.

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 10th Feb 2009 15:16
...actually... LOL

Darn - nothing is sacred anymore - darn meddling optimizers!

-----

On a side note - I'm buried adding "Web Service" capability to my portable web server which has a CRM backend - Native MySQL or ODBC backend, CGI support - and its designed so your "scripts" and "custom applications" are actually linked in versus thunked out - In short - its fully compiled exe code running web applications and pages etc without the scripting.... unless you opt to go with the CGI interface.... Very challenging little project. Once I get around to adding SSL - I think I won't have a need for apache or IIS any longer... except maybe UDDI. Hmm...

Anyway - I've rambled enough...
Just thought that might interest you a bit IanM

--Jason

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 10th Feb 2009 17:12
Quote: "the compiler may detect the tail-recursion and replace the CALL statement with a JMP instead."


What if you declared an automatic variable in the function or passed a parameter. Wouldn't the stack finally blow?

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 10th Feb 2009 18:30
Maybe, maybe not - again this would need to be tested with a specific compiler, but:

This is a simple tail recursion:
void ThisFunc(int a) { ThisFunc(a); }

This isn't so simple, but could still be optimised away:
void ThisFunc(int a) { ThisFunc(a+1); }

This is a simple tail recursion (unused variable will be optimised away):
void ThisFunct() { int a=1; ThisFunc(); }

Basically, if you can conceive of a way to carry out the function without using a stack, then the optimiser could[b] do it too </obvious statement>

Quote: "Darn - nothing is sacred anymore - darn meddling optimizers!"

I'll ask them to stop improving them immediately

Slayer93
20
Years of Service
User Offline
Joined: 5th Aug 2004
Location: I wish I knew
Posted: 11th Feb 2009 21:44
Didn't think the end of loop would be out of scope, my bad...

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 11th Feb 2009 21:49 Edited at: 11th Feb 2009 21:51
Not "bad" just "new" something "new" for the day!

Test this ...


I don't KNOW the answer - but I suspect 3,2,1 respectively.

AlexI
19
Years of Service
User Offline
Joined: 31st Dec 2004
Location: UK
Posted: 12th Feb 2009 01:00
Thanks for the information.

I haven't been able to reply for a while because our servers at work are all screwed up, with this virus

http://www.guardian.co.uk/technology/2009/jan/19/downadup-conficker-kido-computer-infection

http://www.f-secure.com/weblog/archives/00001584.html

http://www.microsoft.com/security/portal/Entry.aspx?Name=Worm:Win32/Conficker.B

Login to post a reply

Server time is: 2024-11-25 13:45:37
Your offset time is: 2024-11-25 13:45:37