There is a memory leak related to spawns being sent to the client, I have been trying to solve this over the past few weeks but have been unable to track the leak. I have ruled out the range maps in the zone server, the lua system, and the way we store packets for spawns. I am also pretty sure it is not in the network code. The memory is also not released when the zone shuts down. In a 32 bit build with a single client running around it is easy for the memory to build to a point where it will crash the server, especially in an active zone like frostfang where spawns are constantly created and die on their own, it gets a lot worse if there is multiple client in the game.

To see this leak just log on your own server in a zone with spawns, open task manager and note the memory used by the server, then run around the entire zone and check the memory again, in thundering steppes with all ground spawns and only a few NPC's spawned the memory usage jumped about 200mb, which will never be released. If you run around in an empty zone this does not happen, also if you are in an area of a zone where no spawns will be sent to you it does not happen, that is why I assume it is related to spawns being sent to the client.

I will be double checking everything I already checked but I doubt I will find anything this time around. I could use some help on this cause I am out of ideas.

Ruled out the zone server changes, reverted back to before I started work on it and have the same result. This may have always been an issue just never noticed as we never had a zone as large and as active as frostfang before.

I'll take a look at this again in valgrind when I have time, I noticed on vgemu I was getting less false positives so will try compiling with the c++0x flag and see if that will give some clearer results.

EQ2TC crashed on a malloc, usually is a memory issue.

So turns out this is not a leak and a windows "feature"

The C / C++ runtime memory allocator (invoked by malloc or new) uses the Windows heap to allocate memory. The Windows heap manager has an optimization in which it will hold on to blocks under a certain size limit, in order to be able to reuse them if the application requests a block of similar size later. For larger blocks (I can't remember the exact value, but I guess it's around a megabyte) it will use VirtualAlloc outright.

I seem to remember John saying that he did not see this behavior on Linux, so this would be it.

The problem with this is if we have some one in a populated zone the memory gets allocated for that zone, they move to a new zone and memory for that zone gets allocated, so 2 zones worth of memory, first zone shuts down and windows will hold on to that memory, client moves to yet another zone and it will reuse the memory from the first zone. For a single client it is not much of an issue, however if we have 2 clients logged in and they both move to a third zone together the server will hold onto memory for all 3 zones, some one logs on in a different zone before the first 2 shut down and even more memory is allocated for the 4th zone.

So the more clients moving around through out the world results in larger memory and it never being released, possible for it to be reused though.

We could just deal with it as is or it is possible to manually create a heap for the zone server to use and destroy it when the zone shuts down. I still need to do more research into this though just putting it out here for discussion.

Jabantiz wrote:So turns out this is not a leak and a windows "feature"

HAHAHA
HAHAHAHAHAHAHHA
HAHAHAHAHAHHAAHAHAHHAHAHAHHA ~breathes~

Well, I guess that explains why you couldn't find it IMO, memory is cheap. Unless it's taking up 32GB of RAM for dozen open zones, I would not even consider it a problem. Let Windows manage it, and anyone serious about running a game server will use Linux anyway

Honestly, unless you cannot let it go, I wouldn't sweat it. I've never seen a problem in EQ2TC either (Windows 2003 x86).

Yea this sucked...

It is not a high priority for me any more now that I know what is going on, something to keep an eye on later though.