Slowdown and crash due to enormous memory consumption

[Lord Estraven]

I tried to start a (non-permadeath, normal mode) game with a Human Fighter. On trying to generate the new game, the T-engine crashed, maxing out my CPU and slowing X to a crawl. I had to switch to a VT and manually kill it, and even that was slow; given another few minutes it probably would have locked me out completely.

This was on Slackware 13.37... Has anyone else seen such crashes?

P.S. Game is much, much smoother than it used to be, and uses less CPU when idling. Awesome work DG.

P.P.S. Is there an ASCII-only mode?

Edit: Changed the title because it's not CPU, it's some kind of memory leak. The game uses over 2 gigabytes of cumulative memory and swap, and thus freezes up.

[j-rod]

Yep. I've had that issue on several *nix systems, never figured out the reason. I was suspecting it is video driver related. For instance, running Crunchbang works for the most part with random crashes here and there, whereas Ubuntu 11.04 on the same machine rails CPU and refuses to run. IIRC, even then it only did that after doing full updates to the system. At one point I tried to compile from source just to see if it would make a difference, but then found that some libs needed to compile aren't in repo yet. You can search this forum for my posts and find it easily. I gave up trying to figure it out. If you find something, let me know! I had these issues on a Thinkpad R51, and a Dell Inspiron 6000.

[Lord Estraven]

Hmm. Aren't these all Intel chipset machines? Probably more fallout from the switch to KMS then.

I'd try turning on shadow framebuffer mode, but that's completely broken on Slackware right now, causes X to segfault on start. Don't you just love it when fallback options are broken?

(I suppose I shouldn't look a gift horse in the mouth; X is free, after all. But I still wish that the developers would stop pushing unstable stuff into "stable" versions, or that distro maintainers would use older versions of X, or *something* to avoid these stupid issues.)

[j-rod]

The Dell is an ATI, the Thinkpad is a Radeon Mobile (really old version)

[Lord Estraven]

Tried again...

I noticed a few interesting things actually.

1. CPU was NOT actually being maxed out, it was more like 30%.

2. After the crash, applications were slow to start, and my hard drive was grinding a lot.

It looks like T4 was hogging large amounts of RAM, forcing everything into swap space. Perhaps there's a memory leak?

Edit: yes, the game was using 1.6 gigabytes of swap space, and RAM was entirely filled up. This is absolutely a bug.

[Lord Estraven]

Alright, I got it to actually run... It uses up to 2 GB while loading graphics, then decreases to about 500 MB total during gameplay. The game is playable once loaded (on the off chance that it loads properly), and not slow, but the RAM usage is still far far too high.

Maybe this is a bug in the PNG image rendering? Is there any way I can disable that and use pure ASCII?

Edit: Ah, found ASCII mode, it's in "Graphics Mode" once you start a game. And no, it doesn't fix the problem - in fact, the game starts to rapidly hog memory again after a few minutes of play. I am quite sure there is a memory leak in there somewhere.

[Shoob]

This has happened to me numerous times.

Where I've noticed it most is in menus. Especially the inventory, talent, and level up ones.

Besides loading, which can take a while, I've seen it crash when I scroll through the items.

[Lord Estraven]

Hmm. Are you on Windows? Linux? Mac?

[yufra]

I use a MBP running OSX 10.7 and have also noticed significant slowdowns, in particular with the level-up menu and the talent tab. I have not yet checked if there is a corresponding spike in memory usage.

[greycat]

The amount of time taken to bring up an inventory menu on my system is definitely much longer than expected -- it starts out OK, but after a few hours/levels, it can be on the order of 3 seconds or so, even with only a few dozen things in the menu. Selling to a shop gets slower, and slower, and slower... as my inventory and the shop inventory increase in size.

[Lord Estraven]

Maybe those are different bugs? In this case it's not just the game that's slowing down, it's the whole system, as other applications are getting forced into swap space when ToME is in the foreground.

[Lord Estraven]

Alright, I am going to run T4 in Valgrind and see what it says. Mind, I've never used Valgrind before, so I'll probably come up with something rather stupid. Nonetheless...

... Well that was totally unproductive. As usual it started gobbling up swap space at about 10 megs a second, and the only thing of note Valgrind said was "Server latency 108" when the memory hogging started. Anyone got advice on getting better output out of Valgrind?

[Lord Estraven]

So... Any further comments?

[tiger_eye]

Lord Estraven, first, running with Valgrind is definitely slower, so be patient. Anyway, a few pointers:

If you compile the source yourself, be sure to build with debug options. I believe this is the default option.

Enable core dumps, such as with the command `ulimit -c unlimited` in the bash shell.

Run valgrind: `valgrind --log-file=valgrind1.txt ./t-engine --flush-stdout > out`

For more verbose output, run: `valgrind --log-file=valgrind2.txt -v --leak-check=full --track-origins=yes ./t-engine --flush-stdout > out`

If there is a core dumb, you can analyse it via: `gdb ./t-engine valgrind1.txt.core` and then type "bt" at the prompt.

Analyzing the output can be a chore, so good luck!

[Mithril]

I also have this or a similar bug. Memory consumption slowly increases until the game crashes. Windows 7 64-bit. Intel integrated graphics.