News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

120.2.2/r8163 Win8.1 pak128.DT 2.7 - Crash on using "map overview"

Started by Kobalt, February 05, 2018, 08:09:59 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Kobalt

Hi there,

on using the "map overview" (not sure if correct term: German version: Reliefkarte), the game crashed (online game) on resizing [usually it doesn't]. see screenshot. The server is still running, seems the client crashed solely.

Best regards,
Kobalt


TurfIt

Screenshot is truncated, but that looks like the out of memory error. How big is the map you're playing on?  Simutrans doesn't prevent you from playing on a 'too big' map, but will run out of memory if trying huge maps.

Dwachs

What window did you resize?

What is the size of the game map in tiles?
Parsley, sage, rosemary, and maggikraut.

Kobalt

Quote from: TurfIt on February 05, 2018, 08:41:34 PM
Screenshot is truncated, but that looks like the out of memory error. How big is the map you're playing on?  Simutrans doesn't prevent you from playing on a 'too big' map, but will run out of memory if trying huge maps.

The truncation of the screenshot was necessary because of 64kB file size limit of the forum. The truncation of the error msg. within the "map overview" window couldn't be prevented since the game window was frozen at that point.

The map size: 1024x1024.

Quote from: Dwachs on February 06, 2018, 12:32:30 PM
What window did you resize?

What is the size of the game map in tiles?

The "map overview" window has been resized by me when this error occured.

The map size is: 1024x1024.

TurfIt

1024x1024 isn't huge - should require ~600MB or so with pak128. As long as your computer has that (plus enough extra for win8 bloat)...

If the out of memory is repeatable, I suggest uploading the savegame, and pak128.DT since that doesn't appear to exist anywhere whatever it might be.

Isaac Eiland-Hall

If space is needed to upload somewhere via ftp, lemme know and I can create space. However, anything from Dropbox to Google Drive to OneDrive or others also exist, too, so whatever's easier.

DrSuperGood

An infinite allocation loop can also cause an out of memory error because the application tries to allocate small amounts of space on the heap infinitely. If it tries to allocate small amounts of space infinitly on the stack that causes a stack overflow error.

Ters

Quote from: DrSuperGood on February 07, 2018, 03:43:35 AM
An infinite allocation loop can also cause an out of memory error because the application tries to allocate small amounts of space on the heap infinitely. If it tries to allocate small amounts of space infinitly on the stack that causes a stack overflow error.

I think the stack can be ruled out, because I don't think sim_new_handler, or new_handlers in general, deals with stack allocations.

For the former case, it should be possible to tell if it is a lot of small allocations in a loop or one big one by how long time it takes. When I've had runaway allocations, the application usually hangs for a while. A single massive allocation stops right away. However, there is a gray zone of lesser number of medium sized allocations between these extremes. So how quickly did the game die?

Although the failure seems GUI related, given that it apparently was triggered by a window resize, we have seen some out-of-memory errors due to corrupted save games misleading Simutrans to try to allocate an array for millions or even billions of whatever. Since this appears to be during a networked game, maybe some communication problem is incorrectly handled, leading to an attempt to interpret uninitialized data as a number of elements to allocate memory for. It just happened to coincide with something unrelated the user did.

Dwachs

The map window may indeed be the problem here. It stores an array containing all visible pixels of the map, not one pixel per tile.
Parsley, sage, rosemary, and maggikraut.

prissi


DrSuperGood

QuoteWhen I've had runaway allocations, the application usually hangs for a while.
In games like Warcraft III it will hang for ~1-2 seconds then crash with OOM. Modern processors are so fast that even allocating a few bytes at a time in a reasonably tight loop can cause application memory footprint to increase by gigabytes per second. How long it hangs really depends on how tight the allocation loop is.
QuoteIt stores an array containing all visible pixels of the map, not one pixel per tile.
I am a bit confused by what you mean here. Are you trying to say it stores the entire mini-map in memory even if only a small part of it is visible?

The experimental server game is absolutely massive and I use the mini-map all the time. That said it was more prone for an OOM error when running the x86 build with the mini-map open but that is what happens when the server game takes >3GB in memory to run.

prissi

The minimap contains the entire map (when open).

I am a little surprised a 3 GB memory consumption works at all with a 32 bit build, since windows 32 bit cannot allocate more than 2 GB per program according to documentation ...

Ters

Quote from: DrSuperGood on February 07, 2018, 10:37:18 PM
In games like Warcraft III it will hang for ~1-2 seconds then crash with OOM.

That is "a while" in computer terms.

Quote from: prissi on February 07, 2018, 11:57:18 PM
I am a little surprised a 3 GB memory consumption works at all with a 32 bit build, since windows 32 bit cannot allocate more than 2 GB per program according to documentation ...

We enabled large memory awareness to Simutrans a while back, remember. Revision 7425. Such 32-bit process can use (just under) 3 GiB of user-space memory on 32-bit Windows with large address support (I don't think home editions ever got that, but I'm not sure) and on 64-bit Windows.

prissi

Ok, thank you. Must have remember the home edition limit then.

Back to the problem at hand, I would suspect somewhat a negative uint is to blame there.

DrSuperGood

QuoteI am a little surprised a 3 GB memory consumption works at all with a 32 bit build, since windows 32 bit cannot allocate more than 2 GB per program according to documentation ...
One can build applications in some kind of extra addressing mode. In such case it will not cap memory at 2GB but rather at whatever the OS allows. On actual x86 OSes it will limit to 2GB. However on modern (not XP) x86-64 OSes it can get up to like 3.5 GB as the OS only reserves 500 MB odd.

Still x86-64 is the way to go. A lot of game companies only target that now.

prissi

But a lot of servers and hardware are still running 32 bit OS. Especially lower end hardware though, but that is no problem for Simutrans.

These were still sold with WIndows 10 32 bit in 2016 (still own one such tablet). Also some search on the net suggest 10-15% still use 32 bit Windows systems.