JavaScript error: uncaught exception: out of memory

[sumpfralle]

Approximately once every two hours I receive the following fatal error when running 0ad:

TIMER| common/modern/setup.xml: 199.223 us
TIMER| common/modern/styles.xml: 298.606 us
TIMER| common/modern/sprites.xml: 1.74399 ms
TIMER| common/setup.xml: 441.873 us
TIMER| common/sprites.xml: 654.179 us
TIMER| common/styles.xml: 166.043 us
TIMER| savegame/save.xml: 17.0087 ms
TIMER| GetSavedGames: 22.4247 ms
WARNING: JavaScript warning: gui/common/functions_utility_loadsave.js line 8
reference to undefined property metadata.mods
Saved game to '/home/lars/.local/share/0ad/saves/savegame-0038.0adsave'
ERROR: JavaScript error: uncaught exception: out of memory

Attached you find gdb's stack trace (with Debian's 0ad-dbgsym package installed) and my system_info.txt.

I am using a 32 bit system with 8 GB of RAM. Memory exhaustion does not seem to be relevant (even given the limit of 4 GB per process in a 32 bit system).

The error is not strictly reproducable and does not seem to depend on the map size or other memory-related circumstances. After loading a save game from a time shortly before a crash, the same game works flawlessly for some more hours.

The error even happens while the game is paused.

[Stan]

I usually can reproduce it playing Corinthian Ismuth (4) With four AIs (playing as observer) but I'm not sure whether it's a leak, or just the AIs being too greedy...

[elexis]

ERROR: JavaScript error: uncaught exception: out of memory

I guess that message explains what is happening?

You can reduce the memory use of 0 A.D. by playing with a smaller mapsize and with less AI players. Recommended not beyond "Normal" mapsize.

...

Consider that memory fragmentation can also mean that even despite enough total memory being available, that there may not be a consecutive chunk of memory large enough available to perform the action.

In the reported stacktrace this happens when writing a savegame, so in that case it will need to write a really big amount of consecutive memory.

It would be good if you upload the replay of the match that you played, or at least mention how many AI players and the map/mapsize chosen.

It seems like a case of simply too many entities on the map.

The AI should be more performant and memory conserving, in which case it is a duplicate, otherwise we could only make it impossible to chose larger mapsizes which sounds unattractive.

[sumpfralle]

It seems like a case of simply too many entities on the map.

Maybe my initial report was too concise in this regard: I played very small and bigger maps. In both cases the problem appeared periodically. The period between crashs did not seem to be related to the number of minutes player (i.e. the number of active units) or the map size.

It would be good if you upload the replay of the match that you played.

As I said above, a loaded savegame (stored a few minutes before a crash) can run for quite some time before the next crash. Thus I cannot imagine it to be of use for reproducing the issue.

In the reported stacktrace this happens when writing a savegame ..

Are you sure about that? I cannot really recall the specific situation of that stacktrace, but I guess, the above message Saved game to ... indicates, that this operation was completed before the memory exhaustion (it was just the most recent message in the log output). But I cannot really remember, thus I may be wrong about this detail.

Especially the following observation surprised me:

The error even happens while the game is paused.

This sounds like it would be unrelated to gameplay handling, but maybe connected only to the visualization.

I am sorry, that this issue seems to be really hard to reproduce. I can only imagine, that it is connected to my rather exotic 32 bit architecture. Otherwise it would be a well-known issue, I guess.

[elexis]

Well it's not like there aren't memory leaks in the game.

You could open a program that displays memory use.

On linux one can locate memory leaks using valgrind (quite simple, just running the game in valgrind will show leaks, either as they occur or at the end of the program).

In fact when I do that, I get tons of memory leaks in my graphics driver, so I suggest you look into updating that.

If you find something or can provide further specifics, please reopen this or create a new ticket!

On a small mapsize Out-Of-Memory should really not occur (as in never happened to me).

[sumpfralle]

The valgrind options "--trace-children=yes --leak-check=full" were used. A small map was started and paused immediately. A few hours later the paused game crashed.

[sumpfralle]

I followed your advice regarding valgrind. Attached you find its log output. The game was paused right from the start until it crashed a few hours later (without any interaction).

I am not sure, whether this valgrind output is of any use (the symbol resolution seems to be absent due to the lack of installed dbgsym packages).

Anyway: feel free to let this log data (and the ticket itself) rest, as it seems to affect only a specific environment (maybe the 32 bit system).

Thank you for your time!

[elexis]

There is also the --track-origins=yes flag which may show some more parts of the stacktrace (while also costing more performance and memory).

I had posted some unresolved leaks ​Phab:P171, ​Phab:P172, ​Phab:P173, ​Phab:P174, ​Phab:P175, ​Phab:P181.

Mostly I lack the experience with openGL to determine if the graphics driver leaks originate in the graphics driver itself or in the way pyrogenesis/0ad uses the driver.

I suppose you could try to use different graphics drivers to see if it changes something.

If the leak was in the graphics driver itself, it would probably mean that more apps would crash, which sounds in turn less likely to be missed by the developers of that driver.

[elexis]

After starting a match and almost immediately closing it again.

[sumpfralle]

valgrind with options: --trace-children=yes --leak-check=full --track-origins=yes

[sumpfralle]

Thank you for your hint regarding --track-origins. I installed the debug symbols package and recorded another valgrind log file. The approach was the same: start a small map and pause immediately. The game crashed within the next hour.

I hope, it helps.