ID:567210
 
Resolved
The view() and range() families of procs had a small memory leak when the reference atom straddled multiple tiles.

In addition, memory was being used more and more over time (but freed on world reboot) when handling objects covering multiple tiles.
BYOND Version:493
Operating System:Windows Server 2003
Web Browser:Firefox 11.0
Applies to:Dream Daemon
Status: Resolved (494)

This issue has been resolved.
Problem signature:
Problem Event Name: APPCRASH
Application Name: dreamdaemon.exe
Application Version: 0.0.0.0
Application Timestamp: 4e8ba0c6
Fault Module Name: byondcore.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4e8ba08f
Exception Code: c0000005
Exception Offset: 001185bb
OS Version: 6.1.7601.2.1.0.272.7
Locale ID: 1033
Additional Information 1: a2d8
Additional Information 2: a2d842a187e46785d0457a1f91b0181b
Additional Information 3: 9da5
Additional Information 4: 9da59cf5deb57db9c330282cd22826cd

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

This is on Box Zombies. The game is running pixel movement at 100 FPS. The memory usage of the Dream Daemon server seems to steadily increase, even when no new content is being created, and all content that is spamishly created seems to be properly cleaning up. Rebooting the server with world.Reboot() does not release any of the memory, but exiting and restarting the DD instance does.

EDIT: Tested, didn't seem to be caused by this.
The most likely cause of this based on how things are working, would be the reuse of 50 objects in a list, which are repositioned and have their icon_state and layer changed to display corpses and blood splatter as necessary.
EDIT: Also, I have a similar system in most other games (and also in this one). However, this other system only displays such effects temporarily, and after 1 second or so moves them to a null location until they are needed again. This system always leaves all 50 objects on the map, and only moves them from one position to another.
The info I have shows that this appears to be a function in one of our data structures, but it's not giving me enough specifics to readily narrow down where. If it is where I think it is, the problem would indicate memory corruption which would be happening somewhere else. I think at a minimum to track this down I'd either need a reliable test case or a stack trace.
http://www.angelfire.com/hero/straygames/BoxZombies.zip
If you head to the right after logging in, and stand near the eastern wall inside the white building with the NPC guard, it seems to produce the issue (this is probably the best place to see the corpse effects that I think are causing it). Also, this memory problem seems like it may be reliant on a player being online, even though the game itself should continue running the same either way.
I've moved this back into the official forums, since you're able to post in the official trackers now.
Anyway, after some more testing, it seems like this might not be an issue with the corpses, but the zombies themselves. Still looking into it.

EDIT: Also, the issue seems worse if you run the game locally in DS, instead of connecting to an instance hosted with DD.
Those host files any help?
No luck. Playing standalone in DS doesn't seem to cause it even after a while, and playing in DS remotely hooked up to a server doesn't cause it either. (I suspect however the problem is server-side, so it should only come up in standalone DS or in DD. Nevertheless I wasn't able to trigger a crash.)

I did see memory use climbing over time, although it would jump up a bit and down a bit; the overall trend was there, albeit slow. What I've been seeing suggests memory is growing at both ends, which could be a sign of fragmentation. It's not from icon loads or sounds or something like that though.
It takes several hours, if not days, for the server to crash, but the memory seems to constantly increase from the start. That other crash report I made seems to have a similar issue, with the memory usage continually increasing.

As far as I can tell, the sheer existence of Zombies seems to cause the memory problem, and having them walk around in any way makes it worse. Perhaps pixel movement is just continually storing every location or something?
I managed to find a minor leak that could be impacting the server and client alike, though it doesn't seem to be the only one.

There are two issues hampering further leak detection in this project. One is the tree placement algorithm, which is taking up a ton of time at startup--it would be nice to be able to disable that or improve on it. The other is the scale.

It would help enormously to have access to the source of this project, as then I could disable portions at need and also see what's going on under the hood that might be a contributing factor. Being able to scale back the project, such as by reducing the number of zombies, would be beneficial. One problem I've run across is that our leak detection code only runs in debug mode, but its memory footprint is so much larger it makes the server impossible to run, so scaling back would be a huge benefit. As always you can email me any source at [email protected].
In response to Lummox JR
Lummox JR wrote:
As always you can email me any source at [email protected].
Sent it

One is the tree placement algorithm, which is taking up a ton of time at startup--it would be nice to be able to disable that or improve on it. The other is the scale.
Fixed it. Though, I had trees disabled when hosting myself, so they probably aren't the issue.

Being able to scale back the project, such as by reducing the number of zombies, would be beneficial.
As I mentioned, there should only be about 100 zombies when playing alone, which shouldn't be much of an issue (Paradise City uses 10,000, with more AI). The SpawnZombies() proc can be used to change how many Zombies are created per target. RangeLocate() takes care of keeping them dynamically on the map, and activating ZombieAI().

One problem I've run across is that our leak detection code only runs in debug mode, but its memory footprint is so much larger it makes the server impossible to run, so scaling back would be a huge benefit.
I assume this is BYOND's debug mode? Since debug mode in the game should be on already...
I found one "true" leak in the server that explains the issue you were having, and a few cases of "bloat" on both the server and client that would have been cleaned up eventually but benefited from being more proactive.

The leak was related to the use of view() and similar procs in pixel movement situations. Being able to disable stuff in the source helped a great deal to narrow this down.

The bloating was in several forms. The client and server were both keeping some information around longer than they needed to, even though it was cleaned up at the end of the program (in the client's case, turf map resets caused by moving also helped trigger a cleanup). In addition, I discovered the server was allocating and freeing memory much more than it needed to, which was at best clouding the issue. With all these issues taken care of, your demo appears to be memory-stable in Dream Daemon. Based on that change I'm going to mark this report as closed.
Lummox JR resolved issue with message:
The view() and range() families of procs had a small memory leak when the reference atom straddled multiple tiles.

In addition, memory was being used more and more over time (but freed on world reboot) when handling objects covering multiple tiles.
Release date?
We're planning to put 494 into a public beta tomorrow.
Will that be an actual release through the software? or just an official post about it in the forums?
No, I'll put a link up and (pending completeness) we might do some kind of announcement post. It has to be tested more because of the maptext stuff and the switch to DX9 (which has caused a problem with at least one user in private testing). Anyway, I can't guarantee dates but we'll do what we can. At the very least we'll do a build of the latest so it can at be tested more privately.
In response to Tom
Tom wrote:
We're planning to put 494 into a public beta tomorrow.

Amen to that.
In response to D4RK3 54B3R
D4RK3 54B3R wrote:
Amen to that.

Meh, if they don't release it as a patch through the pager, most people won't get it, and since it requires 494 to play on 494, that means I still can't update my server to make pixel movement games playable (or even hostable).
In response to Tom
Tom wrote:
We're planning to put 494 into a public beta tomorrow.

Sorry to take this off topic conversation off topic, but is the custom installer thing in said build? I'm curious to see how it works out. I assume it lets us make an installer that works a lot like commercially installed games (shortcuts, folders, exe, so on) that also installs BYOND much like some commercial games install .NET frameworks or Java runtimes?