Crashing during builds, cannot connect debugger to build, freezing that only happens in build...

TL;DR version of my pain:

  • A freeze occurs when scrolling through an inventory, but only in builds; never in the editor.
  • When I attempt to make a debuggable development build using the Mono backend, the build process crashes.
  • When I am lucky and manage to make a build, I cannot keep the debugger connected. As soon as I try to put in a breakpoint, the debugger stops.

First Problem: Build-Only Freezing

  • When testing a build, I bring up and scroll through the inventory for the first time, the game freezes indefinitely, meaning the only way out is to kill the process in task manager.
  • It happens every time in builds.
  • It never happens in the editor.
  • When the freeze occurs, the CPU usage is listed at about 0%, much lower than the normal usage. This indicates a possible problem with thread-locking. However, any code we authored that may be relevant to this issue is strictly main-thread only.
  • While there is sometimes a brief pause in the editor, it only occurs when the inventory first opens, not when a scroll occurs. No relevant console logs or errors appear when scrolling occurs. In other words, the editor indicates no problems.

Second Problem: Crashing During Builds

  • Our project normally releases with IL2CPP. In order for debugging to be possible, I switch to the Mono backend. This crash started after switching to Mono.
  • I tried clearing up space on the relevant hard drives, which seemed to work to allow one build. But then, after having cleared sufficient space, the crashes came back.
  • Error is: “Microsoft Visual C++ Runtime Library” “The application has requested the Runtime to terminate it in an unusual way.”
  • EDIT: I’ve done a complete Library reimport in desparation. This worked. But wtf?

Third Problem: Debugger Instantly Disconnects

  • When I was lucky making a debuggable build, I tried connecting the debugger to it. It successfully connected, but then as soon as I added a breakpoint, the debugger detached.
  • In the debug ouput, it says: The program 'Unity' has exited with code 1 (0x1).
  • This happens every time.
  • I tried making a new build with the option to wait for an attached debugger checked, but am now facing problem 2 again with the build process crashing.
  • After successfully making a build with the wait for debugger option, the problem still happens.

If you have any tips on how I could approach these problems, or have any other useful information, it would be strongly appreciated!

Thanks
-Steve

Editor version: 2021.3.15f1

Given the number of and nature of these issues I‘d definitely try and rule out the system as cause - if you haven‘t already. Do these issues occur in the same or very similar way on another machine? If not, it‘s simply an issue with your computer.

The first issue - freezing but only in builds - happens on other computers. The others? Not sure, and don’t have a means to test that.

Problem 1 (NOT) Solved:
There seems to be a very odd bug in how the callbacks for UI layout calculation interact with rendering threads. It is relevant to a rendered 3D preview of an inventory item you have highlighted. It appears that if:

  • You have a camera and objects rendering that are parented to a transform affected by UI layout callbacks. (May not be required.)
  • The objects being rendered by this camera change immediately in response to UI events (without being deferred to a different location like Update()).
  • You’re playing a build; not in the editor.
  • Some other condition that changed within the last 3 months.

Your game will freeze instantly when you interact with the 3D preview due to a thread lock issue where:

  • It gets stuck on a call to release a render target.
  • OR -
  • It gets stuck waiting for a rendering worker thread to finish.

Solution:

  • Unparent the transform which is a parent to the camera and the objects it renders. (Implement OnEnable/Disable/Destroy() to emulate some of the features lost by unparenting, like activation/deactivation/destruction with its parent.) (May not be required.)
  • Cache the data that is given in response to UI changes, and defer the act of updating the view with that data to some safe location like Update().

However, the fact that this is an issue in the first place is kind of a problem to throw at Unity QA.

EDIT NEVER MIND IT STILL HAPPENS