Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ Python ➜ Memory leakage

Memory leakage

It is now over 60 days since the last post. This thread is closed.     Refresh page


Posted by Reno   (8 posts)  Bio
Date Mon 18 Dec 2006 05:40 AM (UTC)
Message
Hrmm... in relation to my last post about paused threads to call a function after a period of time, I finally used the simple solution of a MUSH timer firing every 0.1 seconds. What is being fired is this:

def cureHerb():
global herbbalance
if len(herbqueue) != 0:
if herbbalance and not affCheck("anorexia"):
eatHerb(herbqueue[0].cure)
herbbalance = False

The question is, why is this causing a 4 kB memory leakage per second? When using all my timers (this is just one of five or six), I have about 50 kB leakage per second, and at times it goes crazy and goes up to about 2 MB/sec. I can cope with this for a while, but it's really annoying to have it nagging at the back of my head.

One key to solving might be that if I save the script and reload it in MUSH, the memory usage goes down a shitload. However, even though it goes down, it goes down to a value far above what is normal. Around 300-450 MB. I can live with it, but I shouldn't have to. Any ideas as to what the problem might be?
Top

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #1 on Mon 18 Dec 2006 12:26 PM (UTC)
Message
I don't know how Python works and where it declares variables and so forth. But one thing is that you declare herbbalance to be global; I'm assuming that is telling Python that that is a global variable. But you're not doing anything with herbqueue; does that also have to be global?

Otherwise, it might be assuming that herbqueue is local, and allocating memory for it. What you're seeing probably isn't memory leaks as much as just waiting for the garbage collector to kick in.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #2 on Mon 18 Dec 2006 07:16 PM (UTC)
Message
It is out of my control whether or not script engines consume lots of memory. Possibly there is a garbage collector you can manually trigger every 10 seconds or so. I know Lua has such a thing.

My experience with memory usage is that it can be a bit puzzling, and once a program (such as MUSHclient, or DLLs inside it) requests memory from the operating system, I am not sure it ever gives it back, so that the memory usage reported by Windows may gradually increase, or at least never return to its initial state.

The excess memory is probably written to disk in the page file, so even though it may be reporting large amounts of memory usage, it hopefully won't slow down execution much.

As a comparison, my copy of MUSHclient (which is using Lua scripting for its main world), and also has 3 plugins loaded, is using 8944 Kb of memory. It reports being up for 1 day, 19 hours. So, that is about 9 Mb after running almost 2 days.

Perhaps try Lua scripting, see if that makes a difference?

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Ked   Russia  (524 posts)  Bio
Date Reply #3 on Tue 19 Dec 2006 04:29 AM (UTC)
Message
This could be a problem with a combination of timers and Python. Try calling the same function in a loop a few thousand times and see if it still leaks (it really shouldn't leak from the looks of it).
Top

Posted by Reno   (8 posts)  Bio
Date Reply #4 on Wed 20 Dec 2006 04:52 AM (UTC)
Message
I made a function that called all the functions in question ten thousand times each, and did that about a hundred times in a row. Not a leak in sight. It seems I have stumbled upon a compatibility bug of some kind between MUSH and Python, as you say. Nick, any ideas?
Top

Posted by Meerclar   USA  (733 posts)  Bio
Date Reply #5 on Wed 20 Dec 2006 08:05 PM (UTC)
Message
More likely than not what you found is why a great many advanced users hate windows - horrible resource allocation. More often than not, once windows allocate resources they're not released until the system is restarted or some 3rd party trash collector goes thru and frees all the memory that's not actually being used anymore.

Odds are the problem isn't MC, Lua or the interaction between them - it's microsoft's sloppy resource management routines.

Meerclar - Lord of Cats
Coder, Builder, and Tormenter of Mortals
Stormbringer: Rebirth
storm-bringer.org:4500
www.storm-bringer.org
Top

Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #6 on Fri 22 Dec 2006 03:08 AM (UTC)
Message
Quote:

It seems I have stumbled upon a compatibility bug of some kind between MUSH and Python ...


There is no difference internally between Python and (say) Vbscript, except for the word "python" at some point internally. Thus, any compatability should also affect all scripting languages, except Lua which is handled differently.

It is quite possible that whoever implemented the Python scripting interface inadvertently allocated some memory that they never free, every time a script is called.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nexes   (65 posts)  Bio
Date Reply #7 on Thu 04 Jan 2007 04:08 AM (UTC)
Message
Note to self: Restart Mushclient every once in a while.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


24,902 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.