Oolite crashes with many "script.javaScript.error.outOfMemory" error messages

[tsoj]

Since a few days Oolite crashes very often, mostly during a hyperspace jump. I don't think that it coincided with an OXP installation or an update, but I am not 100% sure. I have many OXPs installed so it would take a very long time to search for the OXP that causes this crash (if it is an OXP at all), so maybe someone knows, looking at the log, what could've caused the crash.

Log file

[Day]

Hi tsoj,

it seems to me that one of the oxp (because it's related to javascript) you use either has a memory leak, or uses too much memory.

If it is indeed these kinds of problems, the info in the log file won't help, except the oxp list.

You could check relatively quickly by disabling half of your oxp (move half of them in another directory), that would allow you to identify which half is guilty. Then repeat by enabling all except half of the possibly guilty oxp, until you find the single guilty oxp.
Here as it is a memory issue, it would be better to keep most of your oxp enabled during this research, as they will consume more memory and allow the problem to happen faster.

Could you check first if it is Diplomacy by disabling it? Event if I shouldn't have introduced a memory leak, it could be possible that it asks for too much memory.
I could introduce limitations to the number of stored events if it is necessary.

[Day]

Another idea for the javascript masters here, is it possible to dump the content of the javascript memory?
That would allow us to see which oxp is guilty?

[another_commander]

Some observations after looking at the log:
1. There are messages from very early on about semicolons missing in plist dictionaries like this:
00:08:57.809 [gnustep]: 2021-02-07 00:08:57.809 oolite[17238:17238] File NSPropertyList.m: 1011. In parsePlItem Missing semicolon in dictionary at line 17 char 622. This "line 16 char 622" appears quite a bit, but there are also other occurences. Now, this message does not normally appear with the linux version of Oolite distributed from oolite.org, so the first question here is: Are you using the oolite.org distro-independent binary, a version distributed from your Linux distro's official repository or a version you have built yourself? If the answer is either the second or third case, we need to know what versions of support libraries are being used.
2. There are many errors and warnings from libpng about loading image files. This seems to support the built-from-repo or built-locally cases, because the oolite.org binaries use an older libpng which does not have this kind of issues when loading image files. However, failing to load a texture file could have unpredictable consequences in the game. I would not normally expect crashes, but still.
3. What RAM do you have? There seem to be a LOT of OXPs installed, some of them are memory-hungry too. You may want to run the game and check system memory usage, just in case you are actually reaching your available RAM limits. I don't believe this to be the cause, but best to rule out every little possibility that we can.

While waiting for feedback on the above, there are a few things that you can try to do to help debug this further:
1. Install and run the oolite.org binaries and see if the issue is reproducible. The oolite.org binaries do NOT interfere with any of your installed libraries and run Oolite in a completely water-tight environment, free of the influences of any versions of libraries different that the ones we need. This will tell us if the issues you have are local to your system or expected to be found elsewhere too.
2. Try allocating more memory for the JS runtime. You can do this by editing .GNUstepDefaults and adding the line "jsruntime-size-mib" = X;", where X is the amount of MiB you wish to allocate. The default is 32, so you may want to use something like 64 or more. If your .GNUstepDefaults is in XML format, use the XML equivalent syntax, i.e. <key>jsruntime-size-mib</key><integer>X</integer> or similar.
3. Add the line "dump-stack-for-errors" = YES; (or its XML equivalent if the defaults file is in XML format) in .GNUstepDefaults. This will give us a stack dump whenever there is an error in the runtime and hopefully we will be able to figure out what was happening at the time of the error.

Hope this helps as a starting point.

[tsoj]

Okay,
tldr: I installed the oolite.org development binary and set the javascript memory allocation to 512 MB and the problem seems to be fixed.

details:
I installed Oolite from here: https://aur.archlinux.org/packages/oolite using the software installation GUI Pamac that comes with Manjaro. If I understand correctly the installation is basically getting the source from the 1.90 release from GitHub and then compiling it locally, though I don't really know how to check which libraries were used.

I tried to remove the Diplomancy OXP and even though Oolite didn't crash anymore, it still emitted lots (but less) "ourOfMemory" errors, and it was really slow.

I also tried to increase the allocated memory for javascript, but it didn't change anything, however I believe that the installation just didn't register the GNUstepdefaults properly.

When I am running Oolite I normally have around 1 GB left of free RAM, with Firefox running. The swap is pretty much empty, so I don't think that that was the problem. Normally when I run into memory issues the swap quickly fills up.

The problem also happened when using the development binary from Oolite.org. It didn't crash, but it got really slow again and emitted "outOfMemory" messages. Log: https://gitlab.com/tsoj/test/-/raw/mast ... e-log2.txt
With this installation, however, it helped to increase the javascript allocated memory, I set it to 512 MB I haven't seen any "ourOfMemory" error messages yet (Even if diplomancy is installed).

So it seems like the issue is just that I have too many OXPs installed for 32 MB javascript memory (and that the compiled installation didn't register the GNUstepdefault).