SystemRimworld Build 0.18.1722 rev1210 Linux x86_64
running on a Fedora 26 x86_64 system
uname -a:
Linux <hostname> 4.13.13-200.fc26.x86_64 #1 SMP Wed Nov 15 15:46:36 UTC 2017 x86_64 x86_64 x86_64 GNU/LinuxRimworld started either from Steam or from console (see two different logfiles below)
Bug descriptionAfter a random time into a modded game, the game locks up and can only be terminated by a kill -9. The last message in the log says "Receiving unhandled NULL exception". I could reproduce the lockup about 10x, but the time into the game varies - I can reload the autosave and continue playing for maybe 10 minutes, then I get the lockup again.
Without the mods, the game does not crash.
Attachments
- rimworld_log
- Player.log (this was generated earlier with the same problem, has a stack trace at the end - I don't know how I was able to generate this ...)
- savegame (too big to attach, please tell me how to submit ...)
Additional informationThe problem does
not appear when running the game in
Windows (win10 x64). As the game runs much faster in Linux (in Windows, I have terrible lag every 1-2 seconds), I prefer this OS though ...
I am running with several mods:
Core, HugsLib, Higher Pop Storytellers[v18], More vanilla factions, EdB Prepare Carefully, Nature's Pretty Sweet, Expanded Prosthetics and Organ Engineering, A Dog Said..., The Birds and the Bees, Birds and Bees (EPOE Patch), Harvest Organs Post Mortem - 2.0 [A18], More Vanilla Turrets [B18], Security Plus[v18], Expanded Roofing, Bone Mod, [T] ExpandedCloth, Storage Solutions, Hospitality, Miscellaneous 'CORE', Misc. Training, RimFridge - A18, Wall Light - B18, Trading Spot - A18, [RF] Fertile Fields [b18], [RF] Basic Bridges [b18], [RF] Basic Bridges - Fishing Add-On [b18], More Furniture [B18], Growable Mushrooms, [T] MoreFloors, Straw Floor [A18], Colony Manager, Hardworking animals B18, Billy's Improved Caravan Formation, Better Workbench Management, WM Smarter food selection, Hand Me That Brick, Fluffy Breakdowns, Scaling Roads (B18), [B18] Removable Mt.Rock Roof Patche, [RF] Pawns are Capable! [a18], AllowDeadMansApparel, RunAndGun, Set-Up Camp, QualityBuilder, Carcinoma spreads, Animals Logic, Skill Overhead, Stocked Traders[v18], Path Avoid - A18, Efficient Light, Avoid Friendly Fire
, JTReplaceWalls [B18], I Can Fix It!, Realistic Rooms, Tech Advancing, Blueprints, ResearchPal, Defensive Positions, [FSF] Complex Jobs, Medical Tab, Animal Tab, Work Tab, Relations Tab, Allow Tool, Heat Map, Architect Icons, Wanderer stat, Refugee Stats - A18, ExtendedInspectData [A18], Save Storage & Outfit Settings - A18, BetterMiniMap, Notifications Archiver, CleaningArea, and Steel isn't flammable[v18]
A stack trace (as seen in Player.log above) shows:
#0 0x007fff5a117500 in funlockfile
#1 0x007fff5a117a88 in (Unknown)
#2 0x007fff5a117a98 in (Unknown)
#3 0x007fff5a117aa8 in mono_set_defaults
#4 0x007fff5a117f70 in mono_runtime_invoke
#5 0x007fff5a117fa0 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#6 0x007fff5a117fd0 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#7 0x007fff5a117ff0 in ps_hints_apply
#8 0x007fff5a118300 in ps_hints_apply
#9 0x007fff5a1183e0 in ps_hints_apply
#10 0x007fff5a118650 in ps_hints_apply
#11 0x007fff5a118700 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#12 0x007fff5a118720 in zcfree
#13 0x007fff5a119550 in __libc_start_main
#14 0x007fff5a119610 in zcfree
//Edit:
After freeing some disk space, I can produce a coredump. Reason says: "RimWorldLinux.x86_64 killed by SIGTRAP"
Doesn't that mean the executable has a debugging breakpoint set?
[attachment deleted by admin: too old]
Just to clarify, I actually think this is a basegame bug, as a mod error should throw an error, not throw an exception and crash the game.
Of course, I don't ask you to fix the mod which might cause the trouble.
But I would expect the game to catch the error and show an error message.
Now I got some more crashes, this time with stacktraces and/or coredumps.
I attached the rimworld_log (zipped because it was quite big)
And here's the snippet from the journal including some trace:
Nov 30 12:52:22 <hostname> systemd-coredump[19636]: Process 18668 (RimWorldLinux.x) of user 1000 dumped core.
Stack trace of thread 18668:
#0 0x00007ff5e75659fb raise (libc.so.6)
#1 0x00007ff5e7567800 abort (libc.so.6)
#2 0x00007ff5dee29e52 n/a (libmono.so)
#3 0x00007ff5e83d43b0 __restore_rt (libpthread.so.0)
#4 0x00007ff5e75659fb raise (libc.so.6)
#5 0x00007ff5e7567800 abort (libc.so.6)
#6 0x00000000009f67cc n/a (RimWorldLinux.x86_64)
#7 0x00007ff5dee68cb3 n/a (libmono.so)
#8 0x00007ff5dedcca7e n/a (libmono.so)
#9 0x00007ff5e83d43b0 __restore_rt (libpthread.so.0)
#10 0x00007ff5e75aa9e5 vasprintf (libc.so.6)
#11 0x00007ff5def29a19 n/a (libmono.so)
#12 0x00007ff5def2b601 n/a (libmono.so)
#13 0x00007ff5dee843dc n/a (libmono.so)
#14 0x00007ff5dee845d5 mono_type_get_desc (libmono.so)
#15 0x00007ff5dee8479f mono_type_full_name (libmono.so)
#16 0x00007ff5dee8505d mono_method_full_name (libmono.so)
#17 0x00007ff5deec7040 mono_debug_print_stack_frame (libmono.so)
#18 0x00007ff5dee27d37 n/a (libmono.so)
#19 0x00007ff5dee28f92 n/a (libmono.so)
#20 0x00007ff5dee288d1 n/a (libmono.so)
#21 0x00007ff5dee640f0 n/a (libmono.so)
#22 0x0000000002e07b40 n/a (n/a)
#23 0x0000000041b843f2 n/a (n/a)
#24 0x000000004115ce1c n/a (n/a)
#25 0x0000000041159502 n/a (n/a)
#26 0x00000000411dc3d8 n/a (n/a)
#27 0x00000000406d250f n/a (n/a)
#28 0x00007ff5dedd0bc9 n/a (libmono.so)
#29 0x00007ff5deecc67d mono_runtime_invoke (libmono.so)
#30 0x00000000009b9922 n/a (RimWorldLinux.x86_64)
#31 0x0000000000a2443e n/a (RimWorldLinux.x86_64)
#32 0x00000000009f642c n/a (RimWorldLinux.x86_64)
#33 0x00000000005eaae2 n/a (RimWorldLinux.x86_64)
#34 0x0000000000801529 n/a (RimWorldLinux.x86_64)
#35 0x00000000004547f9 n/a (RimWorldLinux.x86_64)
#36 0x00007ff5e754f88a __libc_start_main (libc.so.6)
#37 0x000000000045df09 n/a (RimWorldLinux.x86_64)
[attachment deleted by admin: too old]
I also have this problem, I have been disabling mods on and off trying to figure out witch one it would be. But I also think that this is a problem in the base game. Also there seems to be a pattern when guns are being fired. Almost 90% of the cases the game crashes with raids because I obviously have to fire a gun lol.
Also this is the exception I have, although I think the exception isn't very relevant. It keeps changing.
Receiving unhandled NULL exception
#0 0x007ffd2055e140 in funlockfile
#1 0x007ffd2055e6c8 in _IO_str_overflow
#2 0x007ffd2055e728 in _IO_default_xsputn
#3 0x007ffd2055e778 in _IO_vfprintf
#4 0x007ffd2055ed08 in vasprintf
#5 0x007ffd2055ee38 in g_free
#6 0x007ffd2055ef18 in mono_debug_print_stack_frame
#7 0x007ffd2055ef58 in mono_method_marked_as_wrapperless
#8 0x007ffd2055efb8 in mono_method_marked_as_wrapperless
#9 0x007ffd2055f278 in mono_method_marked_as_wrapperless
#10 0x007ffd2055f538 in mono_amd64_throw_exception
#11 0x007ffd2055f6f8 in (Unknown)
#12 0x007ffd2055f708 in (Unknown)
#13 0x007ffd2055f718 in (Unknown)
#14 0x007ffd2055f728 in (Unknown)
#15 0x007ffd2055f738 in (Unknown)
#16 0x007ffd2055f748 in (Unknown)
#17 0x007ffd2055f758 in (Unknown)
#18 0x007ffd2055f768 in (Unknown)
#19 0x007ffd2055f778 in (Unknown)
#20 0x007ffd2055f788 in (Unknown)
#21 0x007ffd2055f798 in (Unknown)
#22 0x007ffd2055f7a8 in (Unknown)
#23 0x007ffd2055f7b8 in (Unknown)
#24 0x007ffd2055f7c8 in (Unknown)
#25 0x007ffd2055f7d8 in (Unknown)
#26 0x007ffd2055f7e8 in (Unknown)
#27 0x007ffd2055f7f8 in (Unknown)
#28 0x007ffd2055f808 in (Unknown)
#29 0x007ffd2055f818 in (Unknown)
#30 0x007ffd2055f828 in (Unknown)
#31 0x007ffd2055f838 in (Unknown)
#32 0x007ffd2055f848 in (Unknown)
#33 0x007ffd2055f858 in (Unknown)
#34 0x007ffd2055f868 in (Unknown)
#35 0x007ffd2055f878 in (Unknown)
#36 0x007ffd2055f888 in (Unknown)
#37 0x007ffd2055f898 in mono_set_defaults
#38 0x007ffd205621f0 in mono_runtime_invoke
#39 0x007ffd20562220 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#40 0x007ffd20562250 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#41 0x007ffd20562270 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#42 0x007ffd205623f0 in operator new(unsigned long)
#43 0x007ffd20562430 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#44 0x007ffd20562450 in zcfree
#45 0x007ffd20563280 in __libc_start_main
#46 0x007ffd20563340 in zcfree
EDIT
Apparently it has something to do with this bug in unity: https://issuetracker.unity3d.com/issues/linux-player-standalone-x86-64-builds-with-resolution-window-enabled-crash-in-funlockfile.
The game works fine if you use 32bit on linux, however slightly slower tho :/.
I think I have the same problem as you guys. I thought it was gone when I installed RuntimeGC for B18 yesterday and ran it every now and then, because I could play a few hours without any CTDs, but just now I got a CTD again during a raid (pretty much as soon as my turrets engaged), just as thomas15v said.
Something I want to add for my particular configuration: I use a lot of mods (I think something around 175), and if Rimworld crashes like that, it doesn't get killed properly, but the process stays kind of alive, not producing any CPU load, but still occupying about 1GB of RAM. I don't know whether that has anything to do with my WM (I use SpectrWM, so a tiling WM), but the process just kind of gets shoved into the background, where I have to kill -9 it. I didn't have this problem in A17 with a comparable amount of mods.
My uname -a:
Linux <hostname> 4.13.12-1-ARCH #1 SMP PREEMPT Wed Nov 8 11:54:06 CET 2017 x86_64 GNU/Linux
If it's actually helpful, I could attach some log files, as well, but as there hasn't been any reaction yet to the other log files, I'll abstain from that, for now.
I just tried playing again, and this time it happend before even a single shot was fired, almost immediately after unpausing (during a raid, saved and paused where raiders just entered the map)...
rimworld_log:
<Some stuff from Centralized Climate Control?>
Receiving unhandled NULL exception
#0 0x007fff05d2f840 in funlockfile
#1 0x007fff05d2fdf8 in (Unknown)
EOF
I too am receiving the same error! 64bit Linux as well. Thought it was a mod so I've been adding and removing them constantly but it seems to eventually happen no matter which are installed. I see it most often occurring the second that a bady wounded NPC gets shot, and I assume dies. Is it something to do with the items they drop at that moment? I have also seen it occurring when my pawns are completing tasks such as mining or other activities where resources would be dropped into the gameworld. This may just be a coincidence of me seeing that at the same time as a crash, but it may also be related to the fault so I thought worth mentioning.
Here is the section from my error log which relates.
Receiving unhandled NULL exception
#0 0x007fff37d34dc0 in funlockfile
#1 0x007fff37d35208 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#2 0x007fff37d35218 in operator new(unsigned long)
#3 0x007fff37d35238 in operator new(unsigned long)
#4 0x007fff37d35248 in __run_exit_handlers
#5 0x007fff37d35278 in exit
#6 0x007fff37d35288 in mono_thread_exit
#7 0x007fff37d35298 in mono_method_marked_as_wrapperless
#8 0x007fff37d35558 in mono_amd64_throw_exception
#9 0x007fff37d35718 in (Unknown)
Quote from: 2.71828 on December 05, 2017, 01:09:24 PM
I just tried playing again, and this time it happend before even a single shot was fired, almost immediately after unpausing (during a raid, saved and paused where raiders just entered the map)...
rimworld_log:
<Some stuff from Centralized Climate Control?>
Receiving unhandled NULL exception
#0 0x007fff05d2f840 in funlockfile
#1 0x007fff05d2fdf8 in (Unknown)
EOF
From my repeat reloading and new game starting, it seems that once the bug has first hit at a seemingly random time into the game, even loading from an autosave prior to the bug occurring results in the reload dying seconds in. I have no idea why this would be happening as the reloaded autosave has none of the same events occurring yet still dies in the same manner and is basically unrecoverable after that point.
Do the Devs pick up on bugs reported here in the mod specific forum? If this is believed to be a fault with the base game Unity code in Linux 64bit which only occurs when a mod is installed, should we get this moved to the main bugs forum instead?
Quote from: Supay on December 07, 2017, 12:32:58 PM
Do the Devs pick up on bugs reported here in the mod specific forum? If this is believed to be a fault with the base game Unity code in Linux 64bit which only occurs when a mod is installed, should we get this moved to the main bugs forum instead?
I have no idea and would also like to know whether any of the devs are looking into this or at least have seen this bug report, or not. It doesn't seem to be on the Bugtracker (https://ludeon.com/mantis/my_view_page.php), but other than that: 乁| ･ 〰 ･ |ㄏ.
I'm definitely not expecting some kind of immediate miracle fix, but it would be nice to know what the status of this is, i.e. is it a Rimworld bug, or a Unity bug, or something else entirely. If it's a Unity bug, this is probably out of their hands, anyway. :-\
Quote from: 2.71828 on December 07, 2017, 02:10:46 PM
I have no idea and would also like to know whether any of the devs are looking into this or at least have seen this bug report, or not. It doesn't seem to be on the Bugtracker (https://ludeon.com/mantis/my_view_page.php), but other than that: 乁| ･ 〰 ･ |ㄏ.
I'm definitely not expecting some kind of immediate miracle fix, but it would be nice to know what the status of this is, i.e. is it a Rimworld bug, or a Unity bug, or something else entirely. If it's a Unity bug, this is probably out of their hands, anyway. :-\
That is very true, I didn't think of that and should have. If this is purely Unity then not much they can do, but at least they would be aware and that it badly breaks their Linux 64bit users, though possibly only when using mods. At least we seem to have confirmed that it doesn't affect Windows, or Linux 32bit, which makes it less likely to be due to any particular mod and more likely to be a basegame fault. I may chuck up a post in the main bugs area to link to this one and see if it grabs their attention.
I hope it is ok to post this here. A few of us have been discussing in the Mod Bugs Forum, but we think that it is actually a basegame fault and likely with Unity itself. We weren't sure if devs looked in the Mod Bugs Forum often or at all though, so thought best to post here to bring it to your attention.
The fault only appears to affect Linux 64bit as others have tried Windows and Linux 32bit and the fault does not seem to occur in those. It so far seems to only happen with a mod running, but it doesn't seem to matter which mod is running, as I have tested and had it with as few as 1-3 and as many as 130 with the same result. The details are all in the thread in that forum along with a link to the Unity bugtracker showing the fault we are experiencing. If it is Unity, we are aware that you may not be able to do anything, but it is likely why it has only shown up now in B18 if Rimworld is now on a newer and affected Unity version. There is mention of a workaround in the Unity bugtracker, so I'm hoping you might be able to cobble something together in the meantime, as it is murdering our games at the moment!
https://ludeon.com/forums/index.php?topic=37241.0 (https://ludeon.com/forums/index.php?topic=37241.0)
I posted it under the below link. Kept it brief as already a load of stuff here and I assume if it is confirmed as a basegame/Unity fault this thread till be moved to the main Forum and the new post deleted anyway.
https://ludeon.com/forums/index.php?topic=37471.0 (https://ludeon.com/forums/index.php?topic=37471.0)
I may have a workaround. I had the crash again and again reloading my autosave resulted in an almost immediate crash. I took a punt on that Unity bug report mentioning resolution, but bear in mind I have absolutely no Unity experience and that could mean display resolution or resolution of an activity in the code or something else entirely. I set Rimworld to not be Fullscreen and my autosave has loaded and has been running for a while now without any issue. I'll see how it goes and report back. Please tell me if I am just talking bollocks though!
EDIT: Have been running for a while now with not a single crash. Off to bed now and will try again tomorrow, but looking good so far.
I just tried running Rimworld in windowed mode (which for me is actually still fullscreen when it's the only window on my current screen), and it crashed again, same as before: Rimworld crashed to desktop, still blocks about 940 MB of RAM, has 0% CPU load (I had to kill -9 it again), and rimworld_log says:
[...]
Platform assembly: /home/<username>/.local/share/Steam/SteamApps/common/RimWorld/RimWorldLinux_Data/Managed/Assembly-CSharp.dll (this message is harmless)
Receiving unhandled NULL exception
#0 0x007ffeb5116c80 in funlockfile
#1 0x007ffeb5117230 in (Unknown)
(I'm not sure whether I'm supposed to laugh about the first line, or not...)
I also just tried the 32-bit executable (so 'RimWorldLinux.x86' instead of 'RimWorldLinux.x86_64'), also in window(ed) mode, but that's not an option, either, because (I think) the textures glitch out. My screen was plastered with giant rat skeletons and similar stuff.
But thank you for the second bug report and your investigations. None of the suggestions in this thread seem to work for me (so no Rimworld until this is fixed, which is really frustrating :(), but at least it works for you.
Damn, that's a shame. Maybe I just haven't had it glitch yet then. I played for a couple of hours last night and again this morning with no crash, which is the longest I've been able to.
I've continued playing for up to 3 hours at a time with no crash still. I am using i3wm on Arch in a very minimal setup. I don't know if my specific config avoids the fault by setting to windowed mode, but it seems to work. I tried going back to full screen and it crashed not long in, so definitely something going on with that.
Thanks for reporting back! While I didn't have any luck with Linux (I'm also using Arch, with spectrwm; I thought the window mode not working could be tied to me using a tiling WM, but if it works for you...), but it worked without any problems on Windows the last two days (with even more mods loaded than before). The only problem was the OS...
I'll try playing on Linux again and report back, because on Windows I played past the point where it crashed before. Maybe it works now.
Nope, no bueno, as expected. My safe loaded up without any problems, so I paused, spawned a raid, put down some OP turrets in the vicinity, and unpaused. After a few shots: CTD.
Receiving unhandled NULL exception
#0 0x007fff739cb380 in funlockfile
#1 0x007fff739cb918 in (Unknown)
Although apparently no one cares about this other than the people who are affected, I guess I'll keep posting...
Since I got fed up with using Windows today (not only does Rimworld take much longer to start up, the overall performance is also significantly worse, and today the game locked up entirely, after it slowed down to almost a crawl with a lot of stutters on anything above 1× speed...), I tried a couple of things on Linux again:
- Trying Rimworld out with another WM, this time Xfce. I though it might be worth a try, as using window mode seems to work for Supay. For me, it didn't work. Nothing changed.
- I did a clean reinstall of Rimworld (I don't know why I didn't try this earlier. I probably thought letting Steam verify the files would be enough...):
- Using no mods and a fresh colony, I spawned a raid, placed a couple of turrets, and watched. Nothing out of the ordinary happened, the raiders died, no crashes, just how it's supposed to be.
- I activated a single mod, namely ModSwitch, to see whether this problem is caused by just having any kind of mod activated: No problems. Not even a 3000 Pt. raid meeting an anti-grain-IED and a subsequent chain explosion of ≥ 20 turrets and a couple of batteries lead to any crashes.
- I loaded the mod list of my actual colony (i.e. almost 200 mods), loaded my test colony, spawned a raid and set up defences again. This time, the crash happened just as before: After a couple of shots of who knows how many turrets, Rimworld CTD'd. I guess it happened when one of the raiders died.
This time, at least the 'unhandled NULL exception' was a bit more communicative than before:
Receiving unhandled NULL exception
#0 0x007ffe589778c0 in funlockfile
#1 0x007ffe58977e48 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#2 0x007ffe58977e58 in operator new(unsigned long)
#3 0x007ffe58977e78 in operator new(unsigned long)
#4 0x007ffe58977e88 in __run_exit_handlers
#5 0x007ffe58977eb8 in exit
#6 0x007ffe58977ec8 in mono_thread_exit
#7 0x007ffe58977ed8 in mono_method_marked_as_wrapperless
#8 0x007ffe58978198 in mono_amd64_throw_exception
#9 0x007ffe58978358 in (Unknown) I attached the whole rimworld_log (unedited, except for every instance of my username, which got changed to '<user>'). Maybe this relatively clean log is of any help to anyone who actually wants to help.
Edit:
Because I'm apparently very bored/a masochist, I thought I'd try removing some of my mods to see whether something changes, starting with any mod that I added around the time this topic here was posted. I selected 'Path Avoid' (one of the reasons was that the OP also uses this mod, and that it's probably more error-prone than some kind of xml-only mod), and while without the mod I still get the same crash as always, I don't even get an 'unhandled NULL exception' anymore and rimworld_log just ends after some (probably) completely harmless error message from 'ArchitectIcons'...
[attachment deleted by admin: too old]
I have Path Avoid running and no issue. I also have over 130 mods or so, and still no issue, so long as run in windowed mode under i3wm. Could you try installing i3 with a default config file and seeing if Rimworld works fine for you that way as well? My PC is also ancient, a CPU/mobo nearly 11 years old with only 8GB RAM and a 2011 Nvidia 560Ti. So I don't think it is system capability/performance related, particularly as now my colony is large I am seeing it slow down performance wise yet now with no crash, whereas a handful of mods and no more than a few rooms built with 3 colonists was crashing constantly.
Thank you for your report and for being so persistent about the window manager! ;D I was pretty much ready to install i3 and give it another go, but wanted to test out the last of the 3 WM I have already installed, i.e. xmonad (I used to use xmonad and then switched to spectrwm, because I wanted to get rid of all the Haskell dependencies; Xfce was a fallback WM). I didn't think it would work now, but I just tested my test safe, and got through two dev spawned raids without a crash (once with only vanilla turrets, once with turrets from 'More vanilla turrets' [I thought that might make a difference]). What I did get this time, though, were new error messages of the following kind:
Exception ticking Clark: System.ExecutionEngineException: SIGILL
at (wrapper dynamic-method) RimWorld.InteractionWorker.Interacted_Patch2 (object,Verse.Pawn,Verse.Pawn,System.Collections.Generic.List`1<Verse.RulePackDef>) <0x00000>
at (wrapper dynamic-method) RimWorld.InteractionWorker.Interacted_Patch2 (object,Verse.Pawn,Verse.Pawn,System.Collections.Generic.List`1<Verse.RulePackDef>) <0x00027>
at (wrapper dynamic-method) RimWorld.Pawn_InteractionsTracker.TryInteractWith_Patch1 (object,Verse.Pawn,RimWorld.InteractionDef) <0x004ae>
at Hospitality.Harmony.Pawn_InteractionsTracker_Patch/TryInteractRandomly.Replacement (RimWorld.Pawn_InteractionsTracker,bool&) <0x003f6>
at (wrapper dynamic-method) RimWorld.Pawn_InteractionsTracker.TryInteractRandomly_Patch1 (object) <0x00046>
at RimWorld.Pawn_InteractionsTracker.InteractionsTrackerTick () <0x00151>
at Verse.Pawn.Tick () <0x00372>
at Verse.TickList.Tick () <0x003b8>
(I think 'Clark' might be the name of some raider that got killed?)
I'm now guessing that Rimworld crashed with spectrwm and Xfce, because those WMs react differently to SIGILLs, but I have no idea if that even makes sense. Do you also get these kind of errors?
I guess this means that I can now play on Linux again, but it certainly doesn't mean that there are no problems anymore. Is the error message above of any more use to the devs than what we have posted before? Could we get some kind of feedback?
Ok, it seems I celebrated too early. I just loaded my normal save and unpaused. After a few in-game hours, without any kind of raid happening, Rimworld crashed again, without writing anything useful to rimworld_log, again. The only thing that was at least a tiny bit out of the ordinary was Alpha beavers appearing, which I then tagged for hunting, that's it. I don't think that any of my colonists were even up, because I saved in the middle of the night, and it wasn't even morning yet when the crash happened.
What the flying f* makes Rimworld crash all the time? Why did my test save work all of a sudden?
@Supay: I just thought about something: Are you running 'steam-runtime' or 'steam-native'?
Another (and probably final) report:
I started another colony with a slightly different set of mods (not really less, though), 'steam-runtime' instead of 'steam-native' (which I used before), and xmonad. Yesterday, I could play this colony for a couple of ingame days, without any problems, so I thought using 'steam-runtime' (and its out-of-date libraries) must have done it. Well, of course it hasn't. I just tried to play my old colony again, and after I unpaused: CTD. Then I thought: maybe this save is just fucked, so I reloaded my other, new save, that was working flawlessly yesterday. Guess what: CTD after I loaded the save, paused immediatly, went afk for a couple of minutes because I had to do something, and then unpaused. So this time, the CTD happened immediately after I unpaused. No shooting, no one dying, nothing. Just ye olde 'unhandled NULL exception'
Setting breakpad minidump AppID = 294100
Steam_SetMinidumpSteamID: Caching Steam ID: 76561197990898994 [API loaded no]
The class Vampire.VampireUtility could not be loaded, used in Vampire, Version=1.18.0.0, Culture=neutral, PublicKeyToken=null
The class Werewolf.WerewolfUtility could not be loaded, used in Werewolf, Version=1.18.0.0, Culture=neutral, PublicKeyToken=null
The class Vampire.CompVampire could not be loaded, used in Vampire, Version=1.18.0.0, Culture=neutral, PublicKeyToken=null
The class Werewolf.CompWerewolf could not be loaded, used in Werewolf, Version=1.18.0.0, Culture=neutral, PublicKeyToken=null
The class Werewolf.CompWerewolf could not be loaded, used in Werewolf, Version=1.18.0.0, Culture=neutral, PublicKeyToken=null
Stacktrace:
Native stacktrace:
/home/<username>/.local/share/Steam/SteamApps/common/RimWorld/./RimWorldLinux_Data/Mono/x86_64/libmono.so(+0x91c4d) [0x7f52cc0a4c4d]
/usr/lib/libpthread.so.0(+0x11d9f) [0x7f52da700d9f]
/usr/lib/libc.so.6(gsignal+0x110) [0x7f52d9e17860]
/usr/lib/libc.so.6(abort+0x1c8) [0x7f52d9e18ec8]
/home/<username>/.local/share/Steam/SteamApps/common/RimWorld/./RimWorldLinux.x86_64() [0x9f67cb]
/home/<username>/.local/share/Steam/SteamApps/common/RimWorld/./RimWorldLinux_Data/Mono/x86_64/libmono.so(+0xd0cb2) [0x7f52cc0e3cb2]
/home/<username>/.local/share/Steam/SteamApps/common/RimWorld/./RimWorldLinux_Data/Mono/x86_64/libmono.so(+0x34a7d) [0x7f52cc047a7d]
/usr/lib/libpthread.so.0(+0x11d9f) [0x7f52da700d9f]
[0x405d5d8d]
Debug info from gdb:
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
[...]
Receiving unhandled NULL exception
#0 0x007fff040c7cc0 in funlockfile
#1 0x007fff040c8250 in (Unknown)
I think I'm giving up. None of the people who could probably do something about this seem to give a fuck (for example, the only one who even looked at the last rimworld_log I attached was me, unless the statistics aren't correct). At this time, I'd actually be happy with a 'We'll look into it', 'It's a mod problem, play it without mods' or even 'We don't care, play it on Windows or GTFO', but this is worse.
If I hadn't already sunk so many hours into A17 in the short time that it was possible for me (I bought RimWorld on 9th November, didn't get the memo about B18 approaching and of course neglected to backup any of my mods), I'd get a refund. For me, (at the moment) RimWorld B18 is broken and unplayable.
I'd just like to point out that several people have been reporting this bug which appears to be a base game or even unity engine bug - mods should not be able to cause unhandled exceptions in any software.
We haven't received any response in more than 3 weeks now, which is kind of dissapointing considering the amount of information delivered. At least a one-liner like "seen it, other stuff is more important, on the to do list for Beta 21" would be nice, because it looks like as if noone cares :(
Myself, I'm currently not playing Rimworld because of this bug ...
I'm pretty sure now that the devs really don't care one bit about this and that this won't be fixed. They do seem to look at the bug section of the forum at least occasionally: Example (https://ludeon.com/forums/index.php?topic=37404.0); someone posted a (possible) bug, and it was acknowledged as a bug only a day later by Tynan himself, and then another dev posted two hours later that the bug was already fixed. When I saw this, I thought: 'Wow, that's great support. I bet our issue will be fixed/looked at in now time.' Still, our/your thread is pretty much a support group of 4 people talking among themselves for more than 3 weeks.
Maybe I'm doing the devs an injustice and they're already working on it, but there has literally been zero feedback, so what else am I supposed to think.
Quote from: jooe on December 19, 2017, 11:10:26 AMWe haven't received any response in more than 3 weeks now, which is kind of dissapointing considering the amount of information delivered. At least a one-liner like "seen it, other stuff is more important, on the to do list for Beta 21" would be nice, because it looks like as if noone cares :(
Quote from: 2.71828 on December 19, 2017, 01:18:48 PM
I'm pretty sure now that the devs really don't care one bit about this and that this won't be fixed.
The devs certainly do care about this bug, along with all the other bugs that players have gone out of their way to report. RimWorld wouldn't be anywhere near as polished as it is today without the thousands of bug reports that players have filed. But it's not just this bug that the developers have not responded to recently, as of you take a quick look around the bugs forum you will see that there are dozens of open bug threads that are awaiting input from the devs.
Why is this you might ask?...
Well, and please don't quote me on this, or take this a gospel, as I could be 100% wrong. But my general observation from helping organise the bug forum for the past ~18 months is that the devs seem to work in fairly strict development stages.
After a new
alpha beta is released, ison (and sometimes Tynan) will for a short while go through the bugs being reported from the new beta, fixing them (for their development build) as they go. My hunch is they are just checking in case any game-breaking bugs or issues exist that need an emergency patch. And by way of example, if you currently look back 7-10 pages in the bugs forum you will see dozens of closed threads where ison is the last poster. These threads being B18 bugs that ison has addressed, and then closed the thread to mark it as resolved.
Once they are sure there are no game-breaking bugs, the devs then seem to move onto a heavy development stage where they put their heads down and concentrate entirely on developing whatever features are planned for the next update. And during this particular stage it's rare to see the devs post in the bugs forum, and basically because they are not on the bug fixing stage at this point. I'm pretty sure this is the stage the devs are currently on right now. Which can be seen by the lack of any recent posts by the devs in the bugs forum, and from the limited number of recently closed threads (with those that are closed likely done so by myself because they are non-bugs or duplicate reports etc.).
Then, and usually about a 4-6 weeks before internal testing on the new beta begins, you will see ison methodically working his way through all the open bug threads that have been posted (although they usually start with the bugs on the Mantis first https://ludeon.com/mantis ). It is during this stage that one of the devs, and most likely ison, will almost certainly comment on this bug, and provide an update on its current status and any ETA on a fix. This bug fixing stage then continues until the next update is released, after which the cycle starts again from the top (although I don't know if the shift from Alpha to Beta will change any of this).
Although as I said please don't quote me on the above as it's not official in any way, and is nothing more than my own observation of how the developers allocate their time between updates (my moderator position gives me absolutely zero additional insight or info into the development of the game. As I said, it's purely my own observations as a regular forumite and from regularly manning the bugs forum for the past ~18 months).
So this issue will certainly be addressed, but my prediction is that that won't be until the devs (or possibly just ison) shift to the bug fixing stage of their development cycle. Which is an unknown period of time away from now. Plus due to the nature of this bug, and if it is strictly a Unity problem, then it is likely that the devs will be unable to do anything about it apart from updating Unity for B19 (assuming that's what the next update will be called) and hoping that that will fix the problem. Although that's also assuming there has been a Unity update during this period, which there might not have been (and even if there has been, it would only fix this bug if Unity Technologies fixed this bug in their engine on their end).
So I guess this post by me will have to do in lieu of a post from the devs, and until they move onto the bug fixing stage. And I haven't commented before now because there's basically nothing about this issue that I can comment on, other than to say "thank you for the bug report, the developers will address this when they move onto the bug fixing stage of their development cycle".
Thank you Calahan for taking the time to write this.
Personally, I would have felt much better if you had just written this one line "thank you for the bug report, the developers will address this when they move onto the bug fixing stage of their development cycle". Because now it feels like someone is listening and I can relax and be patient for the time being. Well, relaxing is maybe not the right word as I'll be working night shifts during the holidays... ;)
I'm posting this since it might help some of you. While I'm also convinced it's a base game issue, my mod RunAndGun does seem to trigger it (maybe indirectly). If you have RunAndGun installed, I advice you to put it as high as possible in the load order, as some users reported that this helped. It won't completely solve it, as some people seem to have the issue without any mods loaded, but it might help at least.
Thanks for your advice, but I'm sure that I had RW working with your mod on Linux (I subscribed on 18 Nov 2017), with it already being relatively high on the priority list already, for a few hours before I got my crashes, so I don't think your mod is the culprit. In any case, I already spent too much time trying to make B18 work on Linux, so before there's any kind of feedback from one of the Devs, I won't fiddle around with it anymore.
In any case, thanks for the tip and thank you for your mods! I already had lots of fun with 'RunAndGun' and can't wait to try out your 'Giddy-up!' series some time in the (hopefully not so distant) future.
Been getting those weird crashes with Run And Gun @Roolo mentioned as soon as raiders try to flee at first I was assuming steam just autoruns 32 bit version and its a memory crash, but after a bit of research came to conclusion its this same issue. Was Run and Gun working fine on Linux with A17 version? If thats so, it just means something is damn wrong with new version then and all I can do is wait for next version, which might fix itself. It works fine on Windows and as soon as I turn RunAndGun off in Linux - its works fine even on Linux - no crashes whatsoever regardless of how many mods I use.
I'll miss shooting on the run, but oh well. I really hope there won't be more problems like that one.
Really strange, but running the game trough gdb completely solved this issue for me:
For anyone who wants to try this workaround but doesn't know how to run Rimworld through gdb:
In the command line go to the Rimworld main directory. cd ~/.local/share/Steam/steamapps/common/RimWorld
type gdb
now in gdb, type:
exec-file ./RimWorldLinux.x86 (you only need to do this once)
run ./start_RimWorld.sh
Interesting... I am not prepared typing that in every time i'll wanna play RW though, but thats something at least. I guess i ll try if that does it for me.
I just solved the crashing issue for RunAndGun.
Apparently, this issue occurs when Harmony is used to patch an (implemented) virtual method. Doing this works fine on Windows, but may cause crashes on Unix systems. I recommend any modders to avoid patching virtual methods until this issue is resolved in Harmony.
Quote from: Roolo on February 09, 2018, 09:14:00 AM
I just solved the crashing issue for RunAndGun.
Apparently, this issue occurs when Harmony is used to patch an (implemented) virtual method. Doing this works fine on Windows, but may cause crashes on Unix systems. I recommend any modders to avoid patching virtual methods until this issue is resolved in Harmony.
Wow, thats good news!) Thanks for your patience looking into it!
Quote from: Roolo on February 09, 2018, 09:14:00 AM
I just solved the crashing issue for RunAndGun.
Apparently, this issue occurs when Harmony is used to patch an (implemented) virtual method. Doing this works fine on Windows, but may cause crashes on Unix systems. I recommend any modders to avoid patching virtual methods until this issue is resolved in Harmony.
Thank you for your work, but if you really managed to fix your issues, then I don't think that RunAndGun was the (only) culprit. Yesterday I thought I might try out Rimworld again after a couple of month hiatus, but Rimworld still crashes randomly. Just now, I got ye olde 'unhandled NULL exception' again (on an new save), although I (should) have the latest version of RunAndGun and have it pretty high in the load order:
Receiving unhandled NULL exception
#0 0x007ffec6486e80 in funlockfile
#1 0x007ffec6487428 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#2 0x007ffec6487438 in operator new(unsigned long)
#3 0x007ffec6487458 in operator new(unsigned long)
#4 0x007ffec6487468 in __run_exit_handlers
#5 0x007ffec64874b8 in exit
#6 0x007ffec64874c8 in mono_thread_exit
#7 0x007ffec64874d8 in mono_method_marked_as_wrapperless
#8 0x007ffec6487798 in mono_amd64_throw_exception
Could this be another mod (mis)using Harmony? Or can this happen if there are just too many mods? Currently, I have about ~250 mods active (although I didn't play Rimworld for a couple of month, I did add the occasional new mod here and there...). Does Rimworld just crash with an 'unhandled NULL exception' if it runs out of RAM? I think I was at about 1.2 GB of RAM, maybe 1–2 minutes before the crash, less than 10 minutes after the safe was loaded. That shouldn't be a problem on a 64bit OS, should it?
Do you perhaps use Rimstory mod? I got those crashes when i was using that. Fixed once i disabled it.
Quote from: 2.71828 on May 20, 2018, 11:32:32 AM
Quote from: Roolo on February 09, 2018, 09:14:00 AM
I just solved the crashing issue for RunAndGun.
Apparently, this issue occurs when Harmony is used to patch an (implemented) virtual method. Doing this works fine on Windows, but may cause crashes on Unix systems. I recommend any modders to avoid patching virtual methods until this issue is resolved in Harmony.
Thank you for your work, but if you really managed to fix your issues, then I don't think that RunAndGun was the (only) culprit. Yesterday I thought I might try out Rimworld again after a couple of month hiatus, but Rimworld still crashes randomly. Just now, I got ye olde 'unhandled NULL exception' again (on an new save), although I (should) have the latest version of RunAndGun and have it pretty high in the load order:
Receiving unhandled NULL exception
#0 0x007ffec6486e80 in funlockfile
#1 0x007ffec6487428 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#2 0x007ffec6487438 in operator new(unsigned long)
#3 0x007ffec6487458 in operator new(unsigned long)
#4 0x007ffec6487468 in __run_exit_handlers
#5 0x007ffec64874b8 in exit
#6 0x007ffec64874c8 in mono_thread_exit
#7 0x007ffec64874d8 in mono_method_marked_as_wrapperless
#8 0x007ffec6487798 in mono_amd64_throw_exception
Could this be another mod (mis)using Harmony? Or can this happen if there are just too many mods? Currently, I have about ~250 mods active (although I didn't play Rimworld for a couple of month, I did add the occasional new mod here and there...). Does Rimworld just crash with an 'unhandled NULL exception' if it runs out of RAM? I think I was at about 1.2 GB of RAM, maybe 1–2 minutes before the crash, less than 10 minutes after the safe was loaded. That shouldn't be a problem on a 64bit OS, should it?
Yeah RunAndGun was just one mod that was causing the issue, I never said it was the only culprit. It seems to happen when virtual methods are patched with harmony, and I expect more mods patch virtual methods (I don't think patching virtual methods with harmony
always cause issues, but when moving my patch to a non-virtual method, the problem was solved for RunAndGun). I don't think many mod creators are aware of this, so I'm not surprised that it happens with more mods.
Quote from: Madman666 on May 20, 2018, 11:47:26 AM
Do you perhaps use Rimstory mod? I got those crashes when i was using that. Fixed once i disabled it.
Yes, that's one of the mods I added while I didn't play, because it sounded interesting. Did this, by any chance, also spawn a lot of error in your debug log? Later today I got Rimworld to work for a bit (I started it directly by 'LC_ALL=C ./RimWorldLinux.x86_64 -force-opengl'; I thought it might be worth a try) and it worked for a bit, although I got a lot of errors with a specific pawn, so I killed and resurrected him, and after that most errors were gone and I could play for a bit, before I shut Rimworld down for the moment. I actually suspected Psychology, or something.
I just tried it again and got a CTD less than 10 seconds after unpausing. I guess I'll try disabling Rimstory and report back. EDIT: No, I actually don't. I wanted to try it out, but it seemed like other mods I already used pretty much did what RimStory does already, so that's not the culprit.
Quote from: Roolo on May 20, 2018, 02:17:03 PM[...]
Yeah RunAndGun was just one mod that was causing the issue, I never said it was the only culprit. It seems to happen when virtual methods are patched with harmony, and I expect more mods patch virtual methods (I don't think patching virtual methods with harmony always cause issues, but when moving my patch to a non-virtual method, the problem was solved for RunAndGun). I don't think many mod creators are aware of this, so I'm not surprised that it happens with more mods.
Yes, I didn't want to imply that. Thanks for your work, anyway.
I'll try Madman666's solution and report back. I just think it's weird that I never had any of those problems under A17. Did nobody patch virtual methods before B18?
I am getting this error when trying to create a colony, RimWorld crashes in process of generating map. When I press "start" and it crashes, it writes this to log:
Receiving unhandled NULL exception
#0 0x007ffff285c080 in funlockfile
#1 0x007ffff285c630 in (Unknown)
#2 0x007ffff285c640 in (Unknown)
#3 0x007ffff285c650 in (Unknown)
#4 0x007ffff285c660 in (Unknown)
#5 0x007ffff285c670 in (Unknown)
#6 0x007ffff285c680 in (Unknown)
#7 0x007ffff285c690 in (Unknown)
#8 0x007ffff285c6a0 in (Unknown)
#9 0x007ffff285c6b0 in (Unknown)
#10 0x007ffff285c6c0 in (Unknown)
#11 0x007ffff285c6d0 in (Unknown)
#12 0x007ffff285c6e0 in (Unknown)
#13 0x007ffff285c6f0 in (Unknown)
#14 0x007ffff285c700 in mono_set_defaults
#15 0x007ffff285db10 in mono_runtime_invoke
#16 0x007ffff285db40 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#17 0x007ffff285db70 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#18 0x007ffff285db90 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#19 0x007ffff285dd10 in operator new(unsigned long)
#20 0x007ffff285dd50 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#21 0x007ffff285dd70 in zcfree
#22 0x007ffff285eba0 in __libc_start_main
#23 0x007ffff285ec60 in zcfree
Sometimes it does not crash when creating colony, but I am not sure the exact reason so I am testing it right now
On windows I play with same set of mods, and it does not crash, however overall perfomance is worse.
Lubuntu 18; So for me:
i3wm and windowed mode didn't work;
Launching using gdb gives me black screen
I tried launching rimworld 10 times, it successfully created new map only once and it was completely random. All the other times same error every time I create a map. I checked log file during map generation, but this did not give me any evidence of mod causing it
I don't have rimstory, run and gun or pathfinding mods.
EDIT: It once gave me this error somehow:
Receiving unhandled NULL exception
#0 0x007ffe2323f1c0 in funlockfile
#1 0x007ffe2323f75d in (Unknown)Quote from: Roolo on February 09, 2018, 09:14:00 AM
I just solved the crashing issue for RunAndGun.
Apparently, this issue occurs when Harmony is used to patch an (implemented) virtual method. Doing this works fine on Windows, but may cause crashes on Unix systems. I recommend any modders to avoid patching virtual methods until this issue is resolved in Harmony.
Maybe we could use notepad++ find all in folder function to find all the mods using that method? Could you please paste an piece of code which is similar for all mods that patch virtual method?
Still getting this error on 1.0
Receiving unhandled NULL exception
#0 0x007ffedcadee40 in funlockfile
#1 0x007ffedcadf3d8 in vasprintf
#2 0x007ffedcadf508 in g_free
#3 0x007ffedcadf5e8 in mono_method_full_name
#4 0x007ffedcadf678 in mono_debug_add_method
#5 0x007ffedcae1708 in mono_set_signal_chaining
#6 0x007ffedcae1758 in mono_set_defaults
#7 0x007ffedcae1838 in mono_set_defaults
#8 0x007ffedcae18d8 in mono_set_defaults
#9 0x007ffedcae18f8 in mono_set_defaults
#10 0x007ffedcae1a88 in mono_runtime_invoke
#11 0x007ffedcae1ab8 in mono_print_unhandled_exception
#12 0x007ffedcae1bc8 in mono_method_marked_as_wrapperless
#13 0x007ffedcae1e88 in mono_amd64_throw_exception
#14 0x007ffedcae2048 in (Unknown)
I merged this into one thread and moved it to the Bugs forum.
I suspect it's a Unity issue. But we should review this.
1.0 released and I have different mod selection but still getting this, but now I can generate maps but I can't start game after generating pawns.
Receiving unhandled NULL exception
#0 0x007fd03c7f66c0 in funlockfile
#1 0x007fd03c7f6c48 in vasprintf
#2 0x007fd03c7f6d78 in g_free
#3 0x007fd03c7f6d98 in g_free
#4 0x007fd03c7f6e88 in mono_free_bstr
#5 0x007fd03c7f6ea8 in mono_type_get_desc
#6 0x007fd03c7f6ed8 in mono_type_full_name
#7 0x007fd03c7f6ef8 in mono_method_full_name
#8 0x007fd03c7f6f88 in mono_debug_print_stack_frame
#9 0x007fd03c7f6fc8 in mono_method_marked_as_wrapperless
#10 0x007fd03c7f7028 in mono_method_marked_as_wrapperless
#11 0x007fd03c7f72e8 in mono_method_marked_as_wrapperless
#12 0x007fd03c7f75a8 in mono_amd64_throw_exception
#13 0x007fd03c7f7768 in (Unknown)
#14 0x007fd03c7f7778 in (Unknown)
#15 0x007fd03c7f7788 in (Unknown)
#16 0x007fd03c7f7798 in (Unknown)
#17 0x007fd03c7f77a8 in (Unknown)
#18 0x007fd03c7f77b8 in mono_set_defaults
#19 0x007fd03c7f7d90 in mono_runtime_invoke
#20 0x007fd03c7f7dc0 in mono_thread_create
#21 0x007fd03c7f7e00 in mono_pthread_key_for_tls
#22 0x007fd03c7f7e20 in GC_start_blocking
#23 0x007fd03c7f7ec0 in start_thread
#24 0x007fd03c7f7f80 in clone
Hope that helps. Windows version works perfectly
It's all Mono from what I can see. Mono is the implementation of .NET. I guess the Linux version has an issue... not sure we can do anything about it. :/
(sorry to necro-thread)
I'm getting this same error. Same scenario. Ubuntu 18.04 LTS. Rimworld 64bit running from steam. Lots of mods.
Using the shiny new 1.0.2096 build of Rimworld. Been fiddling with the "which mod is it" troubleshooting, and if it's mods then there's some mod interaction that seems like it would be best described by calculus groups. Sadly, verbose logging via dev mod has given me no hints.
The bottom of the /tmp/rimworld_log:
Quote
Receiving unhandled NULL exception
#0 0x007ffea82a7600 in funlockfile
#1 0x007ffea82a7b98 in vasprintf
#2 0x007ffea82a7cc8 in g_free
#3 0x007ffea82a7ce8 in g_free
#4 0x007ffea82a7dd8 in mono_free_bstr
#5 0x007ffea82a7df8 in mono_type_get_desc
#6 0x007ffea82a7e28 in mono_signature_get_desc
#7 0x007ffea82a7e58 in mono_lookup_internal_call
#8 0x007ffea82a86a8 in mono_upgrade_remote_class_wrapper
#9 0x007ffea82a8728 in mono_op_to_op_imm_noemul
#10 0x007ffea82a8a98 in mono_set_defaults
#11 0x007ffea82a8b78 in mono_set_defaults
#12 0x007ffea82a8c18 in mono_set_defaults
#13 0x007ffea82a8c38 in mono_print_thread_dump_from_ctx
#14 0x007ffea82a8cb8 in (Unknown)
#15 0x007ffea82a8cc8 in (Unknown)
#16 0x007ffea82a8cd8 in mono_set_defaults
#17 0x007ffea82a91d8 in mono_runtime_invoke
#18 0x007ffea82a9208 in mono_print_unhandled_exception
#19 0x007ffea82a9318 in mono_method_marked_as_wrapperless
#20 0x007ffea82a95d8 in mono_amd64_throw_exception
#21 0x007ffea82a9798 in (Unknown)
Resolved to my satisfaction, oddly enough by removing some inactive mods. Weird.
PSA: RimWorld of Magic (steam only) currently triggers this issue if you kill any pawn.
Mod has been fixed. See below for the culprit.
This Harmony patch will crash Linux with funlockfile consistently even if it's a return false:
[HarmonyPatch(typeof(DeathActionWorker_Simple), "PawnDied", null)]
public class Undead_DeathActionWorker_Patch
{
public static bool Prefix(Corpse corpse)
{
return true;
}
}
so is there a solution? like installing different linux distro or window manager? If modded rimworld works for anyone, please paste your distro and windows manager here.
Running 32bits executable is a workaround but that's undesirable.
It's just better to pester the modders that use Harmony into empty methods.
I was able to play for ~100 hrs with 300 mods enabled and zero crashes. Huge raids, caravans, everything worked fine. I used Solus Budgie, played 64bit version in fullscreen.
I've had this unhandled exception problem since 1.0 was released, and after I installed solus budgie, it is gone. I have no idea why this happens, I can only assume that one of those reasons might be true:
> Something to do with window composer that solus budgie is using
> Something to do with Linux Steam Integration that is installed and enabled in solus by default. It allows games to use native libraries instead of provided with steam, and allows to use additional libraries. If this reason is the one, it might also have something to do with native libraries from solus being better for rimword.
> All mods (and I am subscribed to almost all popular mods) removed bad harmony patches (unlikely)
> Rimworld update fixed it
> I was extremely lucky (extremely unlikely)
> Something to do with video drivers (because new nvidia drivers for linux were pushed)
> Linux core was updated or an system library or etc
> I am very far from computer expert so anything could be the reason
I've also noticed that windows and linux perfomance were same, unlike older versions, where linux version had significantly lower loading times with huge list of mods
I have the same problem but notfood's solution did not help I've removed all mods that have this Harmony patch. The crash happens regardless if I use opengl fix launcher or normal one. It crashes when I make a new game and click on terrain. Using version 1.0.2231 rev1156
Receiving unhandled NULL exception
#0 0x007ffd8747ba80 in funlockfile
#1 0x007ffd8747c108 in psiginfo
#2 0x007ffd8747e278 in psiginfo
#3 0x007ffd8747e7f8 in g_free
#4 0x007ffd8747e8d8 in mono_print_unhandled_exception
#5 0x007ffd8747e9e8 in mono_method_marked_as_wrapperless
#6 0x007ffd8747eca8 in mono_amd64_throw_exception
#7 0x007ffd8747ee68 in (Unknown)
#8 0x007ffd8747ee78 in (Unknown)
#9 0x007ffd8747ee88 in (Unknown)
#10 0x007ffd8747ee98 in (Unknown)
#11 0x007ffd8747eea8 in mono_set_defaults
#12 0x007ffd8747f290 in mono_runtime_invoke
#13 0x007ffd8747f2c0 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#14 0x007ffd8747f2f0 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#15 0x007ffd8747f310 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#16 0x007ffd8747f490 in operator new(unsigned long)
#17 0x007ffd8747f4d0 in std::vector<core::basic_string<char, core::StringStorageDefault<char> >, std::allocator<core::basic_string<char, core::StringStorageDefault<char> > > >::~vector()
#18 0x007ffd8747f4f0 in zcfree
#19 0x007ffd874802f0 in __libc_start_main
#20 0x007ffd874803b0 in zcfree
UPDATE 20.05.2019:
I was able to get pass that crash by playing around with what mods I'm loading and in what order. The debug log windows pops up with this error constantly showing:
Root level exception in Update(): System.NullReferenceException: Object reference not set to an instance of an object
at RimWorld.NeedsCardUtility.UpdateDisplayNeeds (Verse.Pawn) <0x000c5>
at RimWorld.NeedsCardUtility.DoNeeds (UnityEngine.Rect,Verse.Pawn) <0x00035>
at RimWorld.NeedsCardUtility.DoNeedsMoodAndThoughts (UnityEngine.Rect,Verse.Pawn,UnityEngine.Vector2&) <0x00104>
at (wrapper dynamic-method) Verse.InspectTabBase.TabUpdate_Patch1 (object) <0x00014>
at RimWorld.InspectPaneUtility.UpdateTabs (RimWorld.IInspectPane) <0x000b8>
at RimWorld.Planet.WorldInspectPane.WindowUpdate () <0x00027>
at Verse.WindowStack.WindowsUpdate () <0x00050>
at Verse.UIRoot.UIRootUpdate () <0x0003c>
at Verse.UIRoot_Entry.UIRootUpdate () <0x00014>
at (wrapper dynamic-method) Verse.Root.Update_Patch1 (object) <0x000f9>
Verse.Log:Error(String, Boolean)
Verse.Root:Update_Patch1(Object)
Verse.Root_Entry:Update()
When I'm loading the new map for the first time the game still crashes with this error:
Receiving unhandled NULL exception
#0 0x007fa3a82d54c0 in funlockfile
#1 0x007fa3a82d5b48 in _IO_str_pbackfail
#2 0x007fa3a82d5b88 in setlinebuf
#3 0x007fa3a82d5cc8 in g_free
#4 0x007fa3a82d5ce8 in g_free
#5 0x007fa3a82d5dd8 in mono_free_bstr
#6 0x007fa3a82d5df8 in mono_type_get_desc
#7 0x007fa3a82d5e28 in mono_signature_get_desc
#8 0x007fa3a82d5e58 in mono_lookup_internal_call
#9 0x007fa3a82d66a8 in mono_upgrade_remote_class_wrapper
#10 0x007fa3a82d6728 in mono_op_to_op_imm_noemul
#11 0x007fa3a82d6a98 in mono_set_defaults
#12 0x007fa3a82d6b78 in mono_set_defaults
#13 0x007fa3a82d6c18 in mono_set_defaults
#14 0x007fa3a82d6c38 in mono_print_thread_dump_from_ctx
#15 0x007fa3a82d6cb8 in (Unknown)
#16 0x007fa3a82d6cc8 in (Unknown)
#17 0x007fa3a82d6cd8 in mono_set_defaults
#18 0x007fa3a82d71d8 in mono_runtime_invoke
#19 0x007fa3a82d7208 in mono_print_unhandled_exception
#20 0x007fa3a82d7318 in mono_method_marked_as_wrapperless
#21 0x007fa3a82d75d8 in mono_amd64_throw_exception
#22 0x007fa3a82d7798 in (Unknown)
#23 0x007fa3a82d77a8 in (Unknown)
#24 0x007fa3a82d77b8 in (Unknown)
#25 0x007fa3a82d77c8 in (Unknown)
#26 0x007fa3a82d77d8 in (Unknown)
#27 0x007fa3a82d77e8 in mono_set_defaults
#28 0x007fa3a82d7dd0 in mono_runtime_invoke
#29 0x007fa3a82d7e00 in mono_thread_create
#30 0x007fa3a82d7e40 in mono_pthread_key_for_tls
#31 0x007fa3a82d7e60 in GC_start_blocking
#32 0x007fa3a82d7f00 in start_thread
#33 0x007fa3a82d7fc0 in clone
[attachment deleted due to age]