Debugging editor crashes

I feel like I have more crashes in the editor on Linux than I do on Windows, but it’s hard to say for sure as I’m using ECS which is “easier” to get to crash than “normal” Unity.

However, on Linux, I don’t seem to get a stack trace when the editor crashes, just the “Tell us what happened” dialog.

It seems to generate a mono_crash.mem.blob file however, but after some googling, I couldn’t figure out how to debug them, so I thought I’d ask here.

Maybe some more info on what I’m running:

Fedora Workstation 38 (Sway Spin, Wayland)
Unity 2022.3.4f1
i7 13700KF
RX 6950XT
32 GB RAM
Entire ECS Stack (Entities, Physics, NetCode) on 1.0.11

Ideally I could take a look at what exactly is going on some I can make a proper bug report, but like I mentioned, I have no idea how. On Windows I can usually just chuck the crash.dmp file in Visual Studio with native debugging and see what is going on.

The crashes usually happen when exiting playmode.

Edit: After looking at some logs in the editor I get this, although I don’t know how severe this is:
Your mono runtime and class libraries are out of sync.

This is the stacktrace the logs show, although as I mentioned before I don’t actually know how to debug this. It does seem mono related though?

(Unity:294496): GLib-GIO-CRITICAL **: 18:21:57.538: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed
Refreshing native plugins compatible for Editor in 4.31 ms, found 2 plugins.
mmap(PROT_NONE) failed
Caught fatal signal - signo:6 code:-6 errno:0 addr:0x3e800047e60
Obtained 38 stack frames.
#0  0x007f37f99acb70 in (Unknown)
#1  0x007f37f99fd844 in (Unknown)
#2  0x007f37f99acabe in gsignal
#3  0x007f37f999587f in gsignal
#4  0x007f363f26cc32 in abort
#5  0x007f363f26cb8a in abort
#6  0x007f363f26e8e4 in GC_merge_unmapped
#7  0x007f363f26eb36 in GC_merge_unmapped
#8  0x007f363f274b29 in GC_unmap_old
#9  0x007f363f270f9c in GC_unmap_old
#10 0x007f363f274e75 in GC_finish_collection
#11 0x007f363f23f2ee in GC_finish_collection
#12 0x007f363f23adba in GC_collect_a_little_inner
#13 0x007f363f1ea26f in GC_collect_a_little_inner
#14 0x007f363f1ad49b in GC_alloc_large
#15 0x00000041a24d36 in GC_alloc_large
#16 0x00000041b70980 in GC_generic_malloc
#17 0x00000041b70040 in GC_generic_malloc
#18 0x00000041b5ffd4 in GC_malloc_kind_global
#19 0x00000041b88258 in GC_malloc_kind_global
#20 0x00000041b7ec78 in Burst.Compiler.IL.Server.CompilerServer:FindMethods (Burst.Compiler.IL.Server.CompilationRequest,Burst.Compiler.IL.Server.Caching.CacheManager,Burst.Compiler.IL.CompilerStatistics)
#21 0x00000041b7dee8 in Burst.Compiler.IL.Server.CompilerServer/<>c__DisplayClass17_0:<Compile>b__0 (Burst.Compiler.IL.Server.Caching.CacheManager)
#22 0x00000041b7ce08 in System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Burst.Compiler.IL.Server.LibraryCompilationRequest[]>:Start<Burst.Compiler.IL.Server.CompilerServer/<>c__DisplayClass26_0`1/<<RunTask>b__0>d<Burst.Compiler.IL.Server.LibraryCompilationRequest[]>> (Burst.Compiler.IL.Server.CompilerServer/<>c__DisplayClass26_0`1/<<RunTask>b__0>d<Burst.Compiler.IL.Server.LibraryCompilationRequest[]>&)
#23 0x00000041b7cb28 in Burst.Compiler.IL.Server.CompilerServer/<>c__DisplayClass26_0`1<TResult_REF>:<RunTask>b__0 ()
#24 0x00000041b5ea98 in System.Threading.Tasks.Task:ExecutionContextCallback (object)
#25 0x00000041a6d574 in System.Threading.ExecutionContext:Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
#26 0x00000041b5e660 in System.Threading.Tasks.Task:ExecuteEntry (bool)
#27 0x00000041a6da67 in System.Threading.ThreadHelper:ThreadStart_Context (object)
#28 0x00000041a6d574 in System.Threading.ExecutionContext:Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
#29 0x007f363f046328 in (Unknown)
#30 0x007f363f1e521e in (Unknown)
#31 0x007f363f1e6af3 in (Unknown)
#32 0x007f363f2044f5 in (Unknown)
#33 0x007f363f20433e in (Unknown)
#34 0x007f363f27dacc in (Unknown)
#35 0x007f363f27d75f in (Unknown)
#36 0x007f37f99fb907 in (Unknown)
#37 0x007f37f9a81870 in (Unknown)

Edit: After reinstalling unity from scratch this seems to have just gotten worse. Unity is basically unusable on Linux at this point for me, it will relatively consistently crash on every domain reload… Back to Windows it is for now :confused:

“Your mono runtime and class libraries are out of sync.”
usually this is due to the player module is not right. Not sure if you copied the player built from somewhere else or not, or installed everything from the hub. The former one won’t work basically.

I’ve tried both, installing via the Hub, and installing manually. I think with the former I don’t get that message, but I still get crashes.

It seems to have become less after switching back to OpenGL from Vulkan, but that might be a fluke…

would you mind to attach your log(without the out of sync message) or submit a crash report?

I’ll post here again once it crashes next, and submit a crash report.

It is back to crashing constantly today.

Here is the Editor.log file. I removed some of the licensing information since it seemed to contain access tokens and I don’t know how confidential those are.

I did the following in that session:

  • Boot up Unity
  • Wait for Burst to finish compiling
  • Change a script to force a domain reload
  • Do it again
  • Crash

It will very consistently crash after 2 or 3 domain reloads today, making it basically unusable.

Edit: I forgot to mention, this unity version was installed from the hub, yet it still has the mono runtime warning. Not sure what’s going on there. The unity version was installed yesterday, and the os was set up two days ago, so everything is a pretty fresh install.

there are some weird memory leaks in the log. Do need to further investigate.
Much appreciate if you could actually file the bug.

I think I’ve found the issue for the crash at least, the unity process is exceeding the default maximum of memory map areas a process may have, which is 65530 (on my distro, output of sysctl vm.max_map_count). The reason I think this is the issue is that unity dumps the memory map file (same output as pmap), and this file has 65532 lines, where each line corresponds to a memory map. This exeeds the limit, and with the additional log of mmap(PROT_NONE) failed I assume this is the issue.

There’s a proposed change for Fedora 39 (I’m on 38) which fixes this by default (not having to manually increase the value via sysctl), so it should hopefully be less of an issue in the future for other users running into this issue, if the proposal goes through.

The thing I’m confused about is why unity is allocating this many memory pages in the first place. After I had a ton of crashes I rebooted, and immediately ran Unity, and started working for a few hours and it ran fine. I periodically checked the amount of allocated memory pages with pmap, and it was hovering around 20000, so well below the limit (although still relatively high). Unity also seemed to use less memory in general, though I didn’t check that extensively. No idea what is going on here, but maybe this info can help you.

I’ll increase the limit manually on my machine and see if the crashes continue or not.

1 Like