Game freezes after 20-45 minutes

Are you saying the crash looks like a result of a memory leak, especially during a map move, or due to something else? I have not personally seen crash reports that would indicate a memory leak in these conditions, or experienced it myself, but we have seen some as-of-yet unexplained crash reports during map move. If this is what's going on, that is EXTREMELY useful information and there are a few of us who will get a better night's sleep once we know.

Would you please put your contact information (the best way for me to get in touch with you) in the crash report and mention "Television"? Then PM me. Once you do, we'll find your crash report and get the context we're missing. The more info we have, the easier it is to track these kind of issues down.

If you are experiencing this particular leak, please contact Arbiter Oates (via PM). Our team hasn't been able to reproduce this yet and Arbiter Oates is collecting more details.

This is exactly the same kind of behavior I've seen in the base, but I get it with crafting. I'm already in touch with Arbiter Oates.

The "lag leak" while editing in base used to be a progressive thing after about an hour, but now it starts within 5 minutes. I've mentioned this to Arbiter Kim in the past, but will try getting in touch with Arbiter Oats as well. Thanks.

Don�t say things. What you are stands over you the while, and thunders so that I cannot hear what you say to the contrary. - R.W. Emerson

Yeah, Arbiter Kim did a really good job of digging into this problem last time, but it looks like we didn't end up catching it. This time we're looking at getting a different kind of information and maybe some different tactics for reproducing it (we may need to see your specific bases for example). Even if you talked to Arbiter Kim before, we'd appreciate you contacting Arbiter Oates for this second wave of investigation.

I dropped you a PM with some details Television, as I've been suffering from an apparent memory leak as well.

Yes, since I17. Saw it in Test too. I also get periodic freeze-crashes without an error window when zoning or exiting missions. Those ones I have to kill the process on. I'll do some testing tonight, what should I look for that screams "Memory leak?" How big is City SUPPOSED to be in Taskmanager?

PC running XP Home
Radeon 5770
AMD Athlon X2
4GB RAM
80GB system HD.
(other?)

I can't tell you how big it could possibly get without a leak--if you're standing around with 50 of your friends we're going to load a ton of textures, etc, for them. Especially if it's actually 1000 of your closest friends who each have totally unique costumes and run by you in sequence. However, I wouldn't expect to see it go above 1.3 GB under most normal conditions. Other people on the forums can tell you if they consistently see above that.

What you're looking for with the leak is the game using up consistently more memory all the time. I often see little changes when I move my head around or someone runs by, but if you're just sitting there with memory use climbing...that's a bad sign.

I'd check memory use by CoH by looking in task manager. If you're on Windows that is. If you're using Linux, you're probably cool enough to to know how to do this better than I could tell you.

*cough* kinfocenter *cough*

Actually, KDE4 includes System Load Viewer as part of the default installation. Just need to run CoH in a windowed mode rather than full screen to keep an eye on it.

Most KDE4 distro's just need to right click on the task bar, Add Widget, then select System Load Viewer.

Also, the CoH in-game command /graphfps 7 seems to do a similar real-time monitoring through the game's GUI.

Try this on for size: I just let the game sit at the login screen for about twenty minutes and it's grown to, as of this post, 945,000KB with a steady process rate hovering around ten percent. At the LOGIN screen. Doing nothing.

Time/size

10:02:50 /962,XXXKB
10:03:15/ 972
10:03:30 /977
10:03:45/ 986
10:04:15/ 992
10:04:45/ 1,003
.....
EDIT THE SECOND:
Now at 1,200,000K as of 10:15:10
Rate of increase appears to be approximately 300K/second.

Edit III:
Game froze exiting a mission @ 10:35:00, mem usage stopped @ 1,691,356K. CPU use flatlined. Note: Mem usage fluctuated during actual play, rate of increase no longer consistent and in some cases went down.

Edit IV: son of Edit: Crash output:
Assertion failed

Program: C:\Program Files\City of Heroes\CityOfHeroes.exe
Time: Wed May 19 10:34:38 PM
Process ID: 896
File: c:\src\utilitieslib\utils\superassert.c
Line: 1857
Expression: 0

Error Message: CRT abort() called

ERROR: swDumpStackToBuffer - timeout (258) waiting for dumpHeap is NOT corrupted
Last windows SYSTEM error: Not enough storage is available to process this command.

The /unloadgfx and /reloadgfx commands never fixed memory leaks. But they did purge data that was carried over from one map or zone to another, which would extend the amount of time you could play if you were having a memory leak.

I suspect the function has been rolled into zoning.

What, "top" isn't good enough for you?

A: Kinfocenter was a joke.

B: you'll find that KDE4's System Monitor gives the same effective output as top giving per process information, but also more detailed results in a graphing format that Kinfocenter gives.

Radeon 5770 eh? I assume with the 10.4 drivers?

I'm slipping on my kernel programming hat for a moment to fix a couple minor quibbles, hope you don't mind . Real memory is a subset of virtual memory. The virtual memory column in task manager shows how much address space has been allocated to the process, and the real memory column shows how much of that space is currently paged in to physical RAM. Virtual memory may also include shared pages, such as DLLs that are shared by multiple processes, memory that's swapped out to disk, memory that's been allocated but never touched, or even things like memory mapped I/O to the video card which don't correspond to main memory at all.

So, real memory will always be < virtual memory, and it makes no sense to add the two numbers together.

EDIT: I noticed that in the Windows 7 task manager at least, "real memory" has been renamed to "Memory (Private Working Set)" and "virtual memory" has been renamed to "Commit Size". Those names do describe what the values really are a little better.

Also, the per-process limit for 32-bit programs on Windows is 2GB of address space, not 3GB. 32-bit CPUs can natively address 4GB of virtual memory. Windows by default splits this in half. It reserves the upper 2GB of the address space for the kernel, and gives the lower half to user programs. When a context switch happens, the mappings for the lower 2GB change with the active process, while the upper 2GB remains static for the OS to use.

1.5GB-1.7GB real memory used likely corresponds to hitting 2GB virtual memory allocated once you factor in video buffers and shared pages. It's consistent with the CoH process crashing due to address space exhaustion, so it's really a "2GB crash", not a 3GB crash. The TL;DR version is that it's allocating too much memory and never releasing it. Whether it's an actual leak, or it's just trying to cache too much and needs to be a little less aggressive and recycle more, is impossible to say without extensive debugging.

You can tweak this a little. In XP, you can add the /3GB switch to boot.ini. This changes the setup, so that Windows splits it into 3GB user space and 1GB kernel space. In Vista and Win7, "bcdedit /Set IncreaseUserVa 3072" does the same thing. However, in order for a program to take advantage of this extra space, it has to specifically tell the OS that it's what Microsoft calls "Large Address Aware." 32-bit LAA programs will also be able to use the full 4GB address space when running on a 64-bit OS.

Given the age of the game engine, I'd doubt that CoH is linked with that option, but I don't have the development tools installed right now so I can't check. If anyone has Visual C++ installed, run "dumpbin /headers cityofheroes.exe" and see if there's a line that says "Application can handle large (>2GB) addresses"

Apparently it can. Who'da thunk?

That's what I'm thinking of. You can actually modify previously compiled apps that don't have that option set, and I actually did that with a couple of graphics apps on my 32-bit system. I didn't, however, do that to CoH. (The launcher would just love that, I'm sure.)

What operating system are you using? Windows XP SP2 for instance? Windows 7?

Usually when something like this happens it's because an Internet node between you and the CoX servers goes down.