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.

AppGameKit Classic Chat / Memory usage increases, doesn't seem like it should

Author
Message
mindsclay
12
Years of Service
User Offline
Joined: 1st May 2012
Location: Rocklin, CA, USA
Posted: 22nd Dec 2015 10:45
I noticed that my code was eating memory while idling in the main loop. Eventually it crashing because of the memory usage. So I commented out everything in the main loop in order to isolate the issue.

The below code is the culprit somehow.



Running this with task manager open, I can see the memory usage increase for the executable. Should the memory usage be increasing? Is this normal?
home.wavecable.com/~mindsclay
mindsclay
12
Years of Service
User Offline
Joined: 1st May 2012
Location: Rocklin, CA, USA
Posted: 22nd Dec 2015 10:46
This is using version 15d.
home.wavecable.com/~mindsclay
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 22nd Dec 2015 11:18
Is this in your main loop:

for (int a = 1; a <= 40; a++)


If it is, you are creating 40 text objects every cycle. I'm not sure what happens in C++ if you keep creating a Text object with the same ID. In any case, you shouldn't do it
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 22nd Dec 2015 13:09
Maybe SetTextString is allocating memory. If so, you may need to delete the text object and create a new one every time you want to change the string. Should be easy enough to test.
V2 T1 (Mostly)
Phone Tap!
Uzmadesign
mindsclay
12
Years of Service
User Offline
Joined: 1st May 2012
Location: Rocklin, CA, USA
Posted: 22nd Dec 2015 18:13 Edited at: 22nd Dec 2015 18:19
Quote: "Is this in your main loop:"


No, it is in


******************

CJB: Will try... But it shouldn't be allocating everytime it is used. I am creating the text once (CreateText()) then merely changing its contents. If I need to delete the text object in order to change its content then there is no need for SetTextString.
home.wavecable.com/~mindsclay
Matty H
16
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 22nd Dec 2015 18:28


You can't nest agk::Str() like this since it allocates memory that you must delete yourself, in tier 2 at least anyway.



mindsclay
12
Years of Service
User Offline
Joined: 1st May 2012
Location: Rocklin, CA, USA
Posted: 22nd Dec 2015 18:40 Edited at: 22nd Dec 2015 18:43
Further experimenting shows that the issue is with


When the above code is removed the memory increase stops.

@ Matty: I have agk::Str() nested just about every where and there is no memory usage increase without the above code snippet. I can remove the SetTextString lines and the memory increase still occurs. So the "nesting" of agk::Str() you are referring to is not the issue. That would be a huge oversight in the AppGameKit development if we could not use agk::Str() the way I am using it.

GetPointerX() and GetPointerY() are the only two items, that when removed, stop the memory usage increase. Something is going on with GetPointer.

(P.S. Is anyone even trying the code I supplied to see if the phenomena actually exists?)
home.wavecable.com/~mindsclay
Hockeykid
DBPro Tool Maker
17
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 22nd Dec 2015 20:34 Edited at: 22nd Dec 2015 20:39
Quote: "That would be a huge oversight in the AppGameKit development if we could not use agk::Str() the way I am using it."


Matty H is correct and it isn't an oversight, it's simply the way c-strings work in C++ (and C). The "agk::Str()" function returns a pointer ("char *") to a c-string that has been dynamically allocated (on the heap). Any dynamically allocated memory must be freed by the user when you're done with it. So you should be doing exactly what Matty H suggested, call "delete []" after you're done using the c-string or you will cause a memory leak.

EDIT:

Also, utilizing static memory (in a global scope) is generally frowned upon. I would suggest moving these declarations into your class declaration:


Sean
mindsclay
12
Years of Service
User Offline
Joined: 1st May 2012
Location: Rocklin, CA, USA
Posted: 29th Dec 2015 02:28
Except that merely using agk::Str() does not show the memory increase. I have left my example code (minus GetPointer() and using a static values for mouseX and mouseY) running for hours in a loop and the memory usage never increased at all.
I am not saying you are incorrect, I am saying that the experimental data does not support your claim. I will try your suggestion, but it does not explain why using GetPointer() exhibits the memory increase while not using GetPointer does not show a memory increase.

in the example code given to me:


Why is 'str' being used again in the second line? Using merely 'string' works, and has been suggested by every person helping in C++ forums. None of them has mentioned what you are suggesting.
home.wavecable.com/~mindsclay
Hockeykid
DBPro Tool Maker
17
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 29th Dec 2015 08:05
Quote: "Except that merely using agk::Str() does not show the memory increase. I have left my example code (minus GetPointer() and using a static values for mouseX and mouseY) running for hours in a loop and the memory usage never increased at all.
I am not saying you are incorrect, I am saying that the experimental data does not support your claim. I will try your suggestion, but it does not explain why using GetPointer() exhibits the memory increase while not using GetPointer does not show a memory increase."


GetPointer does a return by value (at least according to the definition in the documentation it does) so it shouldn't be an issue. Upload your solution here so I can set it up and try and track down the issue. As far as your experimental data not showing a memory increase from the agk::Str() this is possibly because the amount of memory that agk::Str() is leaking would be very small (a byte per character in the char array) so it will take awhile before you notice (but it's still a memory leak none-the-less). As you can see here in the official AppGameKit Tier 2 documentation agk::Str() returns a "char *" and the description states "if you are calling this command from tier 2 this string must be deleted when you are done with it." (http://www.appgamekit.com/documentation/Reference/Core/Str.htm)


Quote: "Why is 'str' being used again in the second line? Using merely 'string' works, and has been suggested by every person helping in C++ forums. None of them has mentioned what you are suggesting."


The second "str" you are seeing is not the same as "agk::Str()" rather it is the name of your std::string object that you're creating. For example to create a string object with the word "Hello" I could use "std::string MyString("Hello");" However, if you only plan on using the string once you could do the following:



But if you want to use the "std::string" multiple times in the same scope than it's better to do it as Matty H suggested, that way you don't keep creating new string objects (you could keep using "MyString" over and over again without the need to recreate it until it leaves the scope).


Sean
Ancient Lady
Valued Member
20
Years of Service
User Offline
Joined: 17th Mar 2004
Location: Anchorage, Alaska, USA
Posted: 1st Jan 2016 00:27
You can also do without agk::Str, and cleaning up after it, altogether by using sprintf:


C++ sprintf information.

Using sprintf lets you create complex strings (just make sure to make the buffer is big enough for your maximum string, and allow for at least one more character for the null terminator).
Cheers,
Ancient Lady

Login to post a reply

Server time is: 2024-11-25 13:23:48
Your offset time is: 2024-11-25 13:23:48