Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice
  3. Dismiss Notice

Question Debugging editor crashes

Discussion in 'Linux' started by SchnozzleCat, Jul 5, 2023.

  1. SchnozzleCat

    SchnozzleCat

    Joined:
    Oct 23, 2013
    Posts:
    42
    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?

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

    tylerinthezoo

    Unity Technologies

    Joined:
    Jun 15, 2022
    Posts:
    97
    "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.
     
  3. SchnozzleCat

    SchnozzleCat

    Joined:
    Oct 23, 2013
    Posts:
    42
    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...
     
    Last edited: Jul 6, 2023
  4. tylerinthezoo

    tylerinthezoo

    Unity Technologies

    Joined:
    Jun 15, 2022
    Posts:
    97
    would you mind to attach your log(without the out of sync message) or submit a crash report?
     
  5. SchnozzleCat

    SchnozzleCat

    Joined:
    Oct 23, 2013
    Posts:
    42
    I'll post here again once it crashes next, and submit a crash report.
     
  6. SchnozzleCat

    SchnozzleCat

    Joined:
    Oct 23, 2013
    Posts:
    42
    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.
     
    Last edited: Jul 6, 2023
  7. tylerinthezoo

    tylerinthezoo

    Unity Technologies

    Joined:
    Jun 15, 2022
    Posts:
    97
    there are some weird memory leaks in the log. Do need to further investigate.
    Much appreciate if you could actually file the bug.
     
  8. SchnozzleCat

    SchnozzleCat

    Joined:
    Oct 23, 2013
    Posts:
    42
    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.
     
    Last edited: Jul 8, 2023
    tylerinthezoo likes this.