Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Memory Leaking Somewhere
Squeebee Wakawaka
Newbie Savant
Join date: 22 Feb 2006
Posts: 28
01-21-2008 22:19
Well, I finally hit that magic time when I discover that my code is getting so lengthly that I am getting stack/heap collisions just from the script itself without it actually doing anything. This of course means I get to start pruning stuff into other scripts and start using link messages (more), but in the meantime I found that I have a state that leaks memory:

From: someone

state History
{
state_entry()
{
llListen(DIALOG_CHANNEL, "", NULL_KEY, "";); //LISTEN FOR DIALOG RESPONSES
Current = 0;
SendHistoryRequest("PREVIOUS";);
}

listen(integer channel, string name, key id, string message)
{
if (message == "<< Prev";)
{
SendHistoryRequest("PREVIOUS";);
}
else if (message == "Next >>";)
{
SendHistoryRequest("NEXT";);
}
else if (message == "Select";)
{
state Idle;
}
}

http_response(key id,integer status, list meta, string body)
{
if (id == HTTPKEY)
{
if (status != 200 && status != 499)
{
llSay(0, "ERROR: There has been a problem communicating with the back end, Resetting. Status: " + (string)status);
state default;
}
else
{
list lbody=llParseString2List(body,["\n"],[]);
string temp = llList2String(lbody, 0);
list VideoInfo = llParseString2List(temp, ["#"],[]);
MediaURL = llList2String(VideoInfo, 0);
MediaName = llList2String(VideoInfo, 1);
MediaLength = llList2Integer(VideoInfo, 2);
Current = llList2Integer(VideoInfo, 3);
llMessageLinked(LINK_THIS, 401, str_replace(MediaName, "&", "&";), (key)"LCD";);
llDialog(ActiveUser, "\n\t\tUser: " + llKey2Name(ActiveUser) + "\n\n\t\tBalance: " + (string)ActiveBalance + "\n\n\t\tCurrent Video: " + MediaName + "\n", ["<< Prev", "Select", "Next >>"], DIALOG_CHANNEL);
}
}
}
}


I'm assuming the leak occurs somewhere in that final else block but I'm afraid memory management has not been a concern of mine to date. I'm reading up in the wiki but if anyone has pointers I would greatly appreciate it.

Just to help, SendHistoryRequest is just a function with an httprequest within it.

Thanks in advance!
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
01-21-2008 22:35
Hmm. Without global variables (particularly global list or string variables), you can't TECHNICALLY have a "memory leak", as all used memory will be freed after the current event handler exists. You might be using up a lot of memory (maybe that str_replace?), but that's a slightly different beast. Do you have any idea how much data is being returned, how many newlines and '#' characters might be present (and therefore how big the lists are likely to get), etc.?

I do see a couple small issues that may not be memory related though. Calling llString2Integer(...) on a list generated by a llParseString...() I believe might cause problems. You might want to change those to (integer)llList2String(...) instead.
Squeebee Wakawaka
Newbie Savant
Join date: 22 Feb 2006
Posts: 28
01-21-2008 22:40
The backend will only ever return a single string, four elements separated by #. The string has a long string, could be 255 chars or more, then a few numbers.

(integer) on a string function instead of an integer function? Is that really a concern?
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
01-21-2008 22:47
Huh. I doubt there should really be a problem with that much data being manipulated as shown unless it is a really, REALLY big script.

Ah. I guess it actually isn't an issue with integers. It is with vectors and rotations, though. It's just always been my practice to retrieve a list element as the actual type of element (string where there is any question), rather than the final type it is going to be massaged into. Sorry about that.
Jesse Barnett
500,000 scoville units
Join date: 21 May 2006
Posts: 4,160
01-22-2008 03:46
What you posted doesn't show any problems. If what you mean by memory leak, is that you are doing a check somewhere for llGetFreeMemory, then no, you don't have a leak. llGetFreeMemory shows the historic low mark of available heap, not the amount of memory that may actually be available. As the heap is used by manipulating strings, lists, etc in the stack, it is not replaced even though you may have newly available stack. Guess it is really a misnomer and more correctly should be called llGetFreeHeap. Only way to get an accurate reading again is by resetting the script.
_____________________
I (who is a she not a he) reserve the right to exercise selective comprehension of the OP's question at anytime.
From: someone
I am still around, just no longer here. See you across the aisle. Hope LL burns in hell for archiving this forum
Squeebee Wakawaka
Newbie Savant
Join date: 22 Feb 2006
Posts: 28
01-22-2008 07:43
In that case I think it may be just the size of the script at 24,000 characters. When I added this block I had to eliminate a state just to get enough room to allow the script to even initialize. I looked at the values coming back from the database and it always stack collides on a bad foreign charset string, that and memory goes lower and lower but not on every iteration, so it looks like as long as the string being loaded is no longer than the longest string seen previously it doesn't allocate more memory.