ID:1854520
 
Not a bug
BYOND Version:508
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 43.0.2357.65
Applies to:Dream Daemon
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
Overriding a variable that contains a list of objects with varname = list() causes all of the objects inside that list to forever take up memory, Even after world reboot(!), or dd being stopped(!!). and even after running del() on that object(!!!)

Basically, I was making something to brute force running for loops to attempt to trigger another bug report i have up(http://www.byond.com/forum/?post=1852790), and DD starting giving me runtimes relating to null.New() (dispite the fact that that line gives a type path). on a welm, I looked at DD's memory usage, and oh hey, it was 1.8GB.

Here is the project I had made: https://tgstation13.org/msoshit/randomtesting.zip

(its name is because i use this project folder for all my random testing of things)

Numbered Steps to Reproduce Problem:
run project (IN DD, i didn't test running it in DS).
connect.
hit start for loop brute force.
wait.
in about 5 minutes, it will detect a runtime, and restart the loop. you will notice that the amount of loops it goes before runtiming drops as it keeps restarting the loop. (dd will have random ass runtimes as well)
look at dd's memory usage
In dd, hit stop (do not shut down dd)
Than hit start.
You will notice that it's memory usage never drops.

Code Snippet (if applicable) to Reproduce Problem:
See above. (here is the code of the only .dm file in the project)
http://pastebin.com/kNkgWRXR

Expected Results:
that the objects either gc, or at the least, actually get freed if you call del() on them.
Actual Results:
!The_Above()

Does the problem occur:
Every time? Or how often?
Every time.
In other games?
n/a
In other user accounts?
not tested
On other computers?
not tested.

When does the problem NOT occur?
not tested.

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.)
not tested.

Workarounds:
This one is a bit funny, Because if you del() right before clearing the list with listvar = list(), it STILL HAPPENS!

Maybe using cut, or abusing spawns/sleeps.
Thanks for the report. I'll look into it.
Some more notes, running memory stats while this happens shows the objects in the count, until it hits some sort of limit, triggers a "runtime error: Cannot execute null.New()" and then objs becomes 0, and the memory they currently take up never drops. (it also stops reporting that memory)

server mem usage:
Prototypes:
obj: 1864 (15)
mob: 1880 (1)
proc: 8728 (53)
str: 14312 (495)
appearance: 15112 (4)
id array: 8476 (90)
map: 8192 (0,0,0)
objects:
mobs: 128 (1)
objs: 304886400 (3237141)
datums: 0 (0)
lists: 872 (4)
server mem usage:
Prototypes:
obj: 1864 (15)
mob: 1880 (1)
proc: 8728 (53)
str: 14312 (495)
appearance: 15112 (4)
id array: 8476 (90)
map: 8192 (0,0,0)
objects:
mobs: 128 (1)
objs: 680630400 (7119319)
datums: 0 (0)
lists: 872 (4)
runtime error: Cannot execute null.New().
proc name: forlooptest2 (/mob/proc/forlooptest2)
source file: client.dm,68
usr: MrStonedOne (/mob)
src: MrStonedOne (/mob)
call stack:
MrStonedOne (/mob): forlooptest2()
MrStonedOne (/mob): forlooptest1()
MrStonedOne (/mob): Start For Loop Brute force.()
server mem usage:
Prototypes:
obj: 1864 (15)
mob: 1880 (1)
proc: 8728 (53)
str: 14312 (495)
appearance: 15112 (4)
id array: 8476 (90)
map: 8192 (0,0,0)
objects:
mobs: 128 (1)
objs: 0 (0)
datums: 0 (0)
lists: 200 (4)
I can't help but wonder if this is because of the built-in list recycling. I can see where that could be a possible issue in some weird situations, and SS13 is just the right kind of game to trigger that. If you are seeing the memory jump up, that would explain the other report.

I'll make this a high priority for BYOND 508 and get it into the early betas.
I can confirm this bug still exists on current beta (508.1293), with one change:

The memory leak no longer survives a dd stop or world reboot, how ever it is still present none the less within a round.
I don't want this to hold up the 1294 release, but I have started to look at it (apologies for the delay). Seems like I had misplaced this demo.
Thats quite alright, accidentally fixing the part where it lasted after a world reboot was enough to mostly solve the issues from this.

So far the only annoyance is that this causes the item to not GC and our deletion subsystem detects this and has to del() it (with the amount of instances we have, this is about 0.8 ds per del()).
Bump
Frell it all to Hezmana! All this time I've been looking at this, and I never noticed the glaringly obvious problem in the test project code:

obj/testingobj {
var/blah = 1;
New() {
objects += src;
}
Del() {
objects -= src;
}
}

There's one terribly important line missing from Del().

Gah. If there's a real bug here, it doesn't show up in the demo. Memory only grows in the demo because of the broken code. As soon as I fixed the problem, the memory growth issue vanished.
Lummox JR changed status to 'Unverified'
oh god damn it.


..(), my arch nemesis
With that issue fixed in the regular code at large, does the leak you've been seeing go away? If so I can close this report; if not, maybe you can come up with another demo that shows the problem.
Not that I can tell.

I stumbled on this when i was trying to find the other leak related to atom.locs that i already reported.

And I guess that running it to above memory limits was what triggered the error where it would stick around after a world.reboot()

It still seems odd to me that this can happen to gc'ed objects as well, that sounds like a recipe for hard to find memory leaks (luckily we don't use Del() on /tg/)

But ya, Close this.
Lummox JR resolved issue (Not a bug)