Zugg Software :: View topic - [3.25-3.29b]Slow, severe memory leak [Revisited]

Posted: Fri Sep 10, 2010 9:47 pm

I've been playing on Aardwolf today and doing a lot of stuff with GMCP and I am not getting any memory leaks at all. My memory usage peaks at 35k (with a scrollback size of 1000).

I'll leave it running a while to see what happens, but I really think the problem is something you are doing somewhere in your scripts.

Since somebody mentioned the Status Window above, you might investigate your Status Window items to see if one of them might be causing a leak.

Posted: Fri Sep 10, 2010 11:59 pm

The memory leak varies for me quite a bit as far as slowness goes. Sometimes it'll take an hour to reach 200k, sometimes it'll take 5 minutes.

If I leave CMUD running, it gets up to 500-600k and above.

If it helps, I can send you my package files. I have no clue what else to do otherwise because I know it's with the package settings. Opening up a fresh session and importing the settings causes the same result.

Charneus

Posted: Sat Sep 11, 2010 12:10 am

It won't really help to send me your package files. Since you can reproduce the problem, all I can suggest is turning off various scripts in your package and letting CMUD run overnight until you can narrow down which script is causing it. It's most likely something related to a large string list or database variable.

Posted: Mon Sep 20, 2010 9:21 pm

So, been watching it over the last couple of versions... in 3.27, I haven't seen it go above 150MB, which is pretty good, considering how high it got before.

I'll keep watching for it, maybe an unintentional change was made that fixed it.

Charneus

Posted: Mon Sep 20, 2010 9:26 pm

Thanks for letting me know about this. Makes me feel better about a public release.

Posted: Sat Sep 25, 2010 7:06 am

So apparently, it's not gone.

I think I've narrowed it down, however. The only reason why it appeared gone was because I wasn't doing any killing recently. However, today I did some and watched my memory spring sky high once more. I've narrowed it down to two things, either the #UPDATE command, or gmcp itself. As I stated before, I use %gmcp in my gauges and just use #UPDATE command. I really do prefer to do it this way because it means less variables that clutter my editor, and less chance of corruption. Below are the buttons I use as well as the GMCP trigger I use. This is done on Aardwolf, and each line seems to add about 100k to memory usage or so within battle. As you might imagine after exping for an hour or two, with all the variable changes (including enemy health), it will add up quickly. Hope this helps!

Posted: Mon Sep 27, 2010 7:50 am

Further testing reveals that it's either the gmcp itself or the buttons. In this test, I replaced the #UPDATE portion with setting actual variables. Then I updated the buttons to use these variables instead of the %gmcp data.

I've just spent the past two hours killing endlessly on Aardwolf. My memory usage went up to 330MB. However, as I've stopped killing and I'm writing this, it has decreased to 235MB quite rapidly, where it seems to hover now (which I think is quite high still, and the buttons/gmcp are still being updated, just not as quickly as they were before).

I'm pretty much convinced that gmcp is the culprit here, though I wonder if it's a mixture of Aard's gmcp with CMUD, or if it's solely CMUD. Hopefully this can be figured out.

Charneus

Posted: Mon Sep 27, 2010 7:29 pm

My guess is that the problem arises when actually using %gmcp.whatever expressions in the buttons themselves. I think this causes additional references to be created that point inside the %gmcp table so when new GMCP data is received and CMUD makes a copy of this table, it does not release the previous table because of those references.

I definitely agree that the proper way to use GMCP is to set normal variables and then use those variables in the button captions. I'm not sure there is any way for me to fix the issue when you reference the %gmcp data directly from the button captions.

Posted: Mon Sep 27, 2010 7:47 pm

In my last test, as I noted above, I did away with referencing it directly in the buttons and instead used variables. It still increased quite a bit, and after not killing for a while, it went all the way back down to about 90MB.

So it's not just when you reference %gmcp in the buttons.

Charneus

Posted: Mon Sep 27, 2010 8:14 pm

Going up to 300MB and then back down to 90MB is not really bad depending upon how many different windows you are using and what their scrollback settings are set to. It's the 800MB+ in the original post that I was more concerned with.

I had thought you were saying above that when you replaced the reference in your buttons that the problem got better. I guess I misunderstood.

I did some killing on Aardwolf today with my pretty basic session and didn't get any memory increases at all. So it's not the basic built-in GMCP support, but still something related to how your scripts are using it.

I created a button for my HP gauge and assigned the normal variable in a GMCP trigger to update it automatically. Still didn't run into any memory issue. But I was only able to play for an hour or so with the gauge enabled.

As I've said, about all I can suggest for you to help on this is to remove or disable triggers until the memory does *not* go up to determine exactly which scripts are related to the problem.