[SOLVED Linux] Game consistently crashes after running fine many IG years

[tuk0z]

So, just 6 crashes to the desktop since my last post, from 10 seconds to 5 hours into my save, always as I play (vs game paused) and utterly unpredictable. Hieroglyphic stack frames begin as above but no need to post them I guess since no one around can decipher them. The welcomed v1.3.3159 update added its own layer of little challenges to my loosing battle, as it has become "fearing" more than playing.

[tuk0z]

No CTD for a day and 1/2; might well have found what's causing the Game-starts-to-furiously-crash-after-a-few-IG-years CTD (nmap): the Linux kernel `vm.max_map_count` default value isn't really as adapted to huge Unity/Mono processes as Windows is, curiously
Not crying victory before a couple more days testing, but no more crash for so long is already big. It's been almost a year all my colonies ended up crashing.

lmao since there was seemingly no cure in sight from the game/engine community, Canute quick remark below made me go search on the Linux side of the equation more thoroughly. A better reading of the "il2cpp android] mmap(PROT_NONE) failed" link in first post quickly led me discover a number of Unity-on-Linux closely related if not exact copies of this CTD issue. Posts were thoroughly understandable, yeaah Knowing about the Linux kernel virtual memory wasn't even required, maybe fastened the understanding. Anyway will come back after like 2 more days testing.

Never saw these mmap(PROT_NONE) failed,
must be linux specific error or maybe some mod i don't know (well).

[Canute]

What do you think, it is a problem from linux with unity or unity with linux ?
What do you think could RW (not mods) do to improve it, like some different settings.
It is worth to point dev's on this then ?

[tuk0z]

Hey Canute so far looks it's both Linux and Unity not knowing each other well, but please let me finish testing.  Also if confirmed, RW isn't at fault at all, though it could maybe really really really give its penguins players a visible tip. 
PS It wouldn't surprise me if the CTD happened on almost all Linux distros as soon as one tries playing big, ie by the numbers: pawns / animals ...

[tuk0z]

13 hours playing no crash here. 
Also some curated references :

• Unityci Couple interesting links here eg post #4 "GC_realloc / GC_register_finalizer_ignore_self abort due to mmap(PROT_NONE)"
• Also affects Unturned3 hosts (Windows server incl.)
• And the Oxyde/umod community

All from 2020-10 (earliest mention I found) onwards.

[tuk0z]

Over 20 hours playing with no CTD (or any sort of crash) since I quadrupled the Linux kernel virtual memory setting above Will mark this issue solved.

[Canute]

Fine, you managed it self.
Yes playing with mod's need alot more memory then the vanilla play.
But you know, the curious thing is before Rimworld got a 64bilt client for windows/mac many people used the linux version because it got a 64bit version while all other are still 32bit.
And the 32bit version got problems with the memory allocation because of the 3.2 GB limit :-)

[tuk0z]

Well, last game I could finish was in back 2020 (I guess all the CTDs I had on v1.2 after adding Charlotte's Harmony patch had something to do with this) so can you imagine how many hundred hours it took the dumb of me trying to read logs, remove/test mods and so on? But many Linux users are way better than me to discover platform generic bugs: 5.8% sales and over 38% of bug reports from Linux said one dev but it's been helpful

May I suggest the RW team reduces chances for this to happen again, by adding a reachable tip for their fellow Linux users? Something like (am far from being an English speaker tho):

To Linux users: If playing big i.e. many hundreds of animals (pawns?) with mods, there are chances your game will crash to the desktop as soon as a Unity process requires more memory map areas than the maximum number the Linux kernel provides per process.

Next, if provided the technical guideline should be as neutral as possible (to address most if not all distros users). I dunno but e.g.

To test what your current value is type `sysctl vm.max_map_count`. You can change this setting live using the `sysctl -w vm.max_map_count=262144` as root/sudo (this will be reset next reboot). If that worked you can make it permanent by adding the following line

Code Select Expand

vm.max_map_count = 262144
to a file in /etc/sysctl.d/ (e.g. '/etc/sysctl.d/99-vm.conf')
Reference Linux kernel documentation for /proc/sys/vm/