Descriptive Problem Summary:
A simple BYOND daemon that I created for Linux is slowly taking up all available RAM. It should be using about 1% memory at most, but since the last time I rebooted (last night), it has slowly crept up to almost 30%. The daemon accepts Export()s with passed clients as arguments, accesses a MySQL database using Dantom.DB, and parses/returns the results.
There are only 2 variables that persist between calls, both of which are lists, and I've verified that they are both practically empty (as they should be) so this is not the problem. I've even verified that this isn't due to stray DBConnections, DBQueries, and DBColumns from Dantom.DB. In short, I can't find anything that might be taking up 30% of my system memory.
Does the problem occur:
Every time? Or how often? every time
In other games? FFO has essentially the same problem but is much harder to trouble-shoot; it is hosted in Linux and communicates with the daemon using Export()s; FFO does not use MySQL
On other computers? FFO and the daemon are on different computers
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
The problem with FFO started over 2 months ago back before I had started working on the daemon. I can't test the daemon using a version of BYOND older than 475 because it relies on the client list Export() feature.
If you have some ideas - things I can do to try to isolate the problem - I'd love to hear them. As I've said, the daemon is a very simple program.
ID:106290
 Dec 27 2010, 2:25 pm
|
|||||||||||||
Resolved
| |||||||||||||
Using the for(var/list/L) approach, it seems that client lists from incoming Export()s persist even after Topic() has returned.
| |
You can test the latter by looking for stray lists. I'm not positive if you can do for(var/list/L) to loop through all user lists, but if not then you can use a \ref trick to test the IDs of every potential list. Make note of any lists that contain only strings. If you find a lot of those, then there is indeed a list leak. If you don't really find any evidence of those sticking around, the problem is likely on the DB side.