Sending a client list via world/Export() caused a slight memory leak.
BYOND Version:479
Operating System:Linux
Web Browser:Firefox 3.6.13
Applies to:Dream Daemon
Status: Resolved (480)

This issue has been resolved.
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 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.
It would seem the most likely culprit for your leak is in either the DB code or the new world.Topic() client list support. If it's the latter it should be a simple fix--it could perhaps be over-refcounting.

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.
Using the for(var/list/L) approach, it seems that client lists from incoming Export()s persist even after Topic() has returned.