SVN Wesnoth crashes, major memory/processor issue

JimBass · Post by **JimBass** » November 11th, 2006, 6:47 am

Hello all!

First, I love this game!

Now the less pleasant stuff. I am running the SVN version of Wesnoth on Debian unstable, with a 2.6.18-1 kernel. I updated via svn update on Friday, November 10th. It now reports that my version is "At revision 14197".

Other things which according to the bug pages might be important -
automake is 1.9, compiled from source.
gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)
wesnoth itself is the svn, I have to ./autogen.sh, ./configure, make, and sudo make install to use. No error ever occur during compilation, and I make clean before updating.

I am playing the Northern Rebirth campaign, and I'm on the 2nd scenario. While playing, the game will seem to get stuck on some random activity. This happened about 5 times tonight. First, it was having a bowman walk from point A to B. It happened once in combat. It frequently happens if I try to view profiles, or perform any "right click" action. When it locks up, I ssh in from another computer, get a reading from top of processor use at 17.45 or so, 256 Ram fully used, and 512 Mb of swap fully used. When I issue the command "kill -9 (wesnoth PID), it kills the game, and the processor, ram, and swap all drop down to normal within 10 seconds. kill -15 isn't strong enough, only kill -9 works.

The machine itself is useless, due to the strain it is under. The gui is useless, and the processor is under such strain, even trying ctrl-alt-f(x) to get a terminal outside of X takes forever. I have had the most luck sshing in (still a very lengthy process) and killing it that way.

I am attaching a save file, should anyone want to see if maybe it is just a corrupted save on my part. Here is the readout of what is happening from the terminal that I launch the game from:

showing title screen...
714074817
title screen returned result
found valid cache at '/home/jim/.wesnoth/cache/game.cfg-cache-v1.3-svn-CAMPAIGN_NORTHERN_REBIRTH-HARD' using it
scenario: 'infested_caves'
has snapshot: yes
setting replay to end...
scenario: 'infested_caves'
locale could not be determined; defaulting to system locale
locale could not be determined; defaulting to system locale
found valid cache at '/home/jim/.wesnoth/cache/game.cfg-cache-v1.3-svn-MEDIUM-NORMAL' using it
started music
714179266
showing title screen...
714179275
title screen returned result
found valid cache at '/home/jim/.wesnoth/cache/game.cfg-cache-v1.3-svn-CAMPAIGN_NORTHERN_REBIRTH-HARD' using it
scenario: 'infested_caves'
has snapshot: yes
setting replay to end...
scenario: 'infested_caves'
Turning an undo...
Turning an undo...
Killed

Please let me know if you need anymore info. The laptop itself has no problems, I use it both at work and at home all day every day.

Peace,
JimBass

Post by **Noyga** » November 11th, 2006, 8:47 am

Hello,
Thanks for reporting this.
We are aware of memory consumption problems in trunk.
It takes some time to find where those memory leak come from and fix them.

Post by **SkeletonCrew** » November 11th, 2006, 11:07 am

Thanks for the report, I found the (partial) cause for the memory problems, read this bug report for the details https://gna.org/bugs/?7631. I notified the developer who's more familiar with this part of the code.
I haven't looked at the CPU usage.

Post by **Noyga** » November 11th, 2006, 1:07 pm

Well the CPU usage might be a result of the memory usage : swap issues.... Or not.

Post by **SkeletonCrew** » November 11th, 2006, 1:23 pm

Noyga wrote:Well the CPU usage might be a result of the memory usage : swap issues.... Or not.

When I looked for the memory problems I also tested versions which didn't have the memory problem. These versions still had a much higher cpu usage than 1.1.12 atm. 1.1.12 is at 2.3% when doing nothing, the SVN was IIRC around the 40% cpu usage.

JimBass · Post by **JimBass** » November 11th, 2006, 3:03 pm

Thanks guys. I did see that report on the gna page, (by the way, your link didn't work for me, something about "unknown group" searching for 7631 turns it right up) but I didn't think it crept up as that describes. I'll play more today with both computers side by side. That way I can watch the memory and processor usage as things move along. My initial top report was something like this:

17.45 13.2 5.3

but later when I would catch it sooner, it would be more like:

13.6 5.3 2.3

indicating that it rapidly switches up. Also, I was able to play a good 30 or so minutes with no problems, then all of a sudden, something would happen and it would instantly be unusable.

In short, seems to me like it is some specific event(s) that cause the escalation, and not just that it continuously uses more and more memory. I will test and report my results here.

In any case, thanks again for everyone's work toward such a great game!

Peace,
JimBass

Post by **SkeletonCrew** » November 11th, 2006, 3:36 pm

JimBass wrote:Thanks guys. I did see that report on the gna page, (by the way, your link didn't work for me, something about "unknown group" searching for 7631 turns it right up) but I didn't think it crept up as that describes.

I put a point behind the link... but here again https://gna.org/bugs/?7631

At my system it also doesn't always happen but sometimes, and it doesn't creep up it goes up with 60 MB per minute while doing nothing. I look forward to see you further findings.

JimBass · Post by **JimBass** » November 11th, 2006, 4:31 pm

I stand corrected! It does creep up continuously for me as well. There are some strange things I noticed. If I hit ctrl-o or ctrl-s (open or save a game) the processor use will drop to 0. That seems to suggest (to my non-coding mind) that the problem is something in gameplay, as I have no problem with the title screen, or when play is suspended by the open/save dialog screne.

Attached is a series of screenshots, in .png format.

pregame.png is the output of htop before I start wesnoth, just to give a baseline.
creeping.png shows the memory usage skyrocket, and the processor starts going nuts
plateau.png is where the creep stopped, and actually processor use went down from 7+ to low 5
crazy.png is just that, processor use is 18.70!
post.png is the return to normal after the kill -9 took effect

The plateau was strange. While just watching, with the game on but no "playing" happening, the creep seemed to stop. It dropped from processor use over 7 back to the low 5 neighborhood, then started to creep up again.

Whenever the processor use was above 7, I couldn't play. Nothing I did had any effect.

Peace,
JimBass

viorc · Post by **viorc** » November 14th, 2006, 2:43 am

SkeletonCrew wrote:I found the (partial) cause for the memory problems, read this bug report for the details https://gna.org/bugs/?7631. I notified the developer who's more familiar with this part of the code.

Just to report that the memory problem is hugely improved on the last SVN I got today (Revision: 14235). Thanks to everyone who made that possible !

Post by **SkeletonCrew** » November 14th, 2006, 8:00 am

viorc wrote:Just to report that the memory problem is hugely improved on the last SVN I got today (Revision: 14235). Thanks to everyone who made that possible !

Thanks for the info, I'll test tonight, yesterday I tested with build 14216 and it still had the problem, so the change must be very recent.

JimBass · Post by **JimBass** » November 14th, 2006, 1:04 pm

I also build last night with 14235 and it does seem to be corrected!

Peace,
JimBass

allefant · Post by **allefant** » November 14th, 2006, 1:27 pm

Ah, that would also explain why I could not reproduce this anymore here.. I thought I had just added a print call when I experienced it, but must have updated a few SVN revisions as well.

Post by **SkeletonCrew** » November 14th, 2006, 9:39 pm

Yes, the problem is solved I tested and these commits 14218 and 14222 fixed the problem.