What needs t o be resolved before 3.2.0?

Bug 4477 is fixed now.

Bug 4764 is fixed now.

Should we go for beta3 over the weekend, and then 3.2.0 by 1 October if no new serious bugs are reported?

Sounds good to me.

On 21/09/2012 8:01 AM, uckelman wrote:

“Brent Easton” wrote:

I think Bug 4764 - Losing Player Sides when opening module with
different language set.
should be sorted out ASAP as well. I will
try to get on that this weekend.

Bug 4764 is fixed now.

Should we go for beta3 over the weekend, and then 3.2.0 by 1 October if
no new serious bugs are reported?


Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@exemail.com.au

I still think there’s a memory-leak problem in 3.2 related to unloading image tiles and with large modules eventually causes problems.
We seem to experience it on my module’s large maps when we scroll or zoom a lot - the heap fills up and never lets go. Often it results in an out of memory error.

-Mark R.

Thus spake mroyer:

I still think there’s a memory-leak problem in 3.2 related to unloading
image tiles and with large modules eventually causes problems.
We seem to experience it on my module’s large maps when we scroll or
zoom a lot - the heap fills up and never lets go. Often it results in
an out of memory error.

I need exact steps to reproduce this.


J.

It’s fairly simple actually. If you’re in a large module (such as the one I posted for another reason the other day), and you open the Windows Task Manager and monitor the java.exe memory usage, the usage will jump up each time you move your game map window to another section of the map (i.e., bring new tiled sections into memory) or zoom in/out. The memory never appears to be released - it’s usage only grows. Eventually, it will consume the entire allocated heap (and a bit more) and repainting the map images will bog down heavily (often taking 20+ seconds to repaint) and on occasion the game will crash with a message saying “out of memory” or something like that.

-Mark R.

Thus spake mroyer:

“uckelman” wrote:

I need exact steps to reproduce this.

It’s fairly simple actually. If you’re in a large module (such as the
one I posted for another reason the other day), and you open the Windows
Task Manager and monitor the java.exe memory usage, the usage will jump
up each time you move your game map window to another section of the map
(i.e., bring new tiled sections into memory) or zoom in/out.
Eventually, it will consume the entire allocated heap (and a bit more)
and repainting the map images will bog down heavily (often taking 20+
seconds to repaint) and on occasion the game will crash with a message
saying “out of memory” or something like that.

I can’t reproduce it. Can you show me the errorLog from one of these
runs?

J.

Speaking about tiles, how exactly do they work? I mean… are they saved everytime one loads the same module with a different build of Vassal?

It’s weird, because after wiping out completely the AppData/Roaming/VASSAL/tiles and starting MH 1.2 with build 8355 tiles were saved in a certain new folder:

  1. is it normal they took 100 Mb of space when the original images themselves take only 40 Mb or so?

then I quit and reloaded the same module with build 8313
2) is it normal that this time no tiles were saved?

then I quit and reloaded the same module with beta 1
3) is it normal that this time tiles were saved again, and in the same folder as for the 8355 build, for a total of 200 Mb in use?

Finally,
4) shouldn’t there be an automatic tiles removal process when somebody does a “Remove Module”?

I am sure there is none at present because I removed MH 1.2 from the Vassal console (of beta 1) and, while the module didn’t show up anymore in any other build’s console window, the 200 Mb of tiles were still sitting there untouched.

It was strange to have to wipe out 1.2 GB of disk space with only maybe 4 modules still showing in the Vassal console (but also, I guess, multiple istances of the MH tiles whenever I tried a new build).

Maybe tile cleaning up should be included in 3.2.0 official release.

Thus spake barbanera:

Speaking about tiles, how exactly do they work? I mean… are they saved
everytime one loads the same module with a different build of Vassal?

No, new tiles should be computed for a module only when the images in
a module have changed.

It’s weird, because after wiping out completely the
AppData/Roaming/VASSAL/tiles and starting MH 1.2 with build 8355 tiles
were saved in a certain new folder:

  1. is it normal they took 100 Mb of space when the original images
    themselves take only 40 Mb or so?

Yes, because the tiles are gzipped raw image data, so the compression
isn’t as tight as in the image files.

then I quit and reloaded the same module with build 8313
2) is it normal that this time no tiles were saved?

Yes.

then I quit and reloaded the same module with beta 1
3) is it normal that this time tiles were saved again, and in the same
folder as for the 8355 build, for a total of 200 Mb in use?

Yes, but this is due to some changes made after beta1 was released. The
behavior of beta1 wasn’t correct.

Finally,
4) shouldn’t there be an automatic tiles removal process when somebody
does a “Remove Module”?

Yes. Fixed in 3.2.0-svn8370.


J.

I spend a good piece of the weekend trying to reproduce the problems we’d been having in earlier builds and couldn’t. Perhaps it was fixed indirectly by other changes? In general, the repaint of the large map seems more snappy than it use to be (its fully repainting a 1920x1080 monitor in a few seconds which is much quicker than it had been).

As we continue to test, if someone gets an error I will make sure to capture the errorLog.

-Mark R.

Okay, so it happened again this morning. Attached is a screenshot of the memory error, the blank hexgrid waiting endlessly (or a really, really long time) to be re-tiled, and the resource manager showing java.exe over it’s 512MB heap limit. If I increase the heap to, say, 1024 MB it doesn’t help - the java.exe usage creeps up to about 1100MB as I scroll around and zoom in/out on the map.

Also attached is the error log as it happened.

-Mark R.

[attachment=0]errorLog.txt[/attachment]

[attachment=1]Out of Memory.png[/attachment]

That’s not a complete errorLog. It doesn’t have the OutOfMemoryError in it, for one thing. It’s also missing the info which should be written by the ModuleManager indicating how the Player was launched. Did you copy this from the errorLog file, or from the errorLog window in the ModuleManager?

I copied it from the errorLog file in the roaming folder.

I am unaware of the errorLog window in the ModuleManager.

is the missing info recoverable?

Thus spake mroyer:

I copied it from the errorLog file in the roaming folder.

I am unaware of the errorLog window in the ModuleManager.

Look in the Help menu.

is the missing info recoverable?

I don’t see how the missing lines could possibly be missing. Are you
sure you copied the complete contents of the file?


J.

I didn’t copy contents of the file at all. I simply renamed the file from errorLog to errorLog.txt (so the forums would allow upload - it won’t allow un-extensioned files to be uploaded). I never touched the contents.

Also, I’ve found the ModuleManager errorLog window. If it happens again, I’ll be very careful and check both the file and the window and post here.

I looked again at the errorLog you posted, and what it shows is that the Module Manager ran for about 4 seconds, and then exited. There’s nothing missing—it’s just not the error log from the run where you ran out of memory. The errorLog is overwritten each time you start VASSAL, so when there’s a problem, you have to grab it before starting VASSAL again.

Alright. I hadn’t opened another VASSAL module after the Memory error, but I very well might have fired off the module manager. :frowning:

I’ll be more careful next time it happens. It’s rare enough it may not happen again for a while.

-Mark R.

I think I’ve finally isolated this issue.

If I scroll around, zoom in and out, until the java.exe has consumed it’s entire heap allocation, then I set the zoom level to 100% or higher (maybe this is related to the size of a tile vs the size of the visible image?) and set the map window to straddle the boundary between two large map images such that a portion of each map is visible, the tiles never stop re-painting themselves causing the map image tiles to blink and flash endlessly (and occasionally, after a while, throw an exception/eek bug). If I reduce the image size to less than 100% (75% in my case) and/or move the window off the map boundary, the flashing/blinking stops and the map repaints itself correctly and only once (at least that I can see).

I can reproduce the blinking-symptom at will now that I know root mechanism.

(The issue can probably be reproduced separately, but just in case I’ve posted the module that I used to cause the issue here: dl.dropbox.com/u/24119799/WAA.zip
It’s 83 MB, just FYI. Run it in v3.2 and set up at least two of the six map segments to reproduce the issue.)

-Mark R.

Thus spake mroyer:

“mroyer” wrote:

I still think there’s a memory-leak problem in 3.2 related to
unloading image tiles and with large modules eventually causes
problems.

I think I’ve finally isolated this issue.

If I scroll around, zoom in and out, until the java.exe has consumed
it’s entire heap allocation, then I set the zoom level to 100% or higher
(maybe this is related to the size of a tile vs the size of the visible
image?) and set the map window to straddle the boundary between two
large map images such that a portion of each map is visible, the tiles
never stop re-painting themselves causing the map image tiles to blink
and flash endlessly (and occasionally, after a while, throw an
exception/eek bug). If I reduce the image size to less than 100% (75%
in my case) and/or move the window off the map boundary, the
flashing/blinking stops and the map repaints itself correctly and only
once (at least that I can see).

To what do you have your max heap set?

The most likely reason this is happening is that the image cache is being
cleared before what’s on your screen is finished painting, which triggers
reloading those same images during the next repaint cycle, which again
causes the cache to clear partway through.


J.