How can I stop Fabric 2.1.6 from hanging for 4-5 minutes when stopping Unity 4.2 Editor?

Questions & Answers
1

When I execute the game through Unity 4.2’s Editor by pushing “Play”, and then pushing “Stop”, the Editor hangs for 4-5 minutes almost every time. (Every once in awhile, the Unity Editor halts the executable in a few seconds like usual)

If I “Break All” inside Visual Studio during this hang, I typically see the callstack:

Boolean Fabric.FabricManager:IsInitialised()+0x17 at:-1
Boolean Fabric.EventManager:IsInitialized()+0x0:at-1
Void Fabric.Component:OnDestroy()+0x0 at:-1

Occasionally I get this callstack:

System.Threading.Thread:Sleep (Int32)+0x18 at /Applications/buildAgent/work/b59ae78cff80e584/mcs/class/corlib/System.Threading/Thread.cs:320
System.IO.DefaultWatcher:Monitor ()+0x7 at:-1

This behaviour seemed to begin when Fabric sound effects were first submitted to the project, and both the duration of each hang and the frequency of hangs-per-close increased as more sounds were submitted.

This hang-on-close does not happen if I build, run and close the game as a standalone executable.

None of my teammates appear to be afflicted by this problem.

I am using the Echo Gina3G sound card (for audio recording), which might be account for the difference, although there are numerous differences between my teammates’ machines. The Gina3G soundcard is an essential part of my machine, so I can’t easily remove it from the equation.

Possibly relevant specs:

  • Unity 4.2
  • Fabric 2.1.6
  • Windows 7 64-bit
  • Echo Gina3G soundcard (driver 8.5)

TaskManager reports Unity.exe constantly using 12%-13% of CPU resources during the hang, which suggests it is completely occupying one of my eight hardware threads.

I profiled Unity.exe with Windows Performance Analyzer during the hang, and it showed:

  • absolutely no activity for ~3.7 minutes (no CPU usage, memory accesses, or hard drive accesses) – which seems consistent with the hypothesis that System.Threading.Thread:Sleep() is being called from Void Fabric.Component:OnDestroy() for some reason
  • then some D3D11-related activity for about ~1.5 minutes
  • and then finally the first “MsgCheck Delay” Windows message of the last ~4.2 minutes of the Editor hanging (my limited understanding is that Windows issues this message once an application has been detected to be nonresponsive)

What could be going wrong?

2

This appears resolved; it seems that two instances of Fabric’s AudioManager crept into the Hierarchy, which seems to have directly caused this havoc.

Also, it should be noted that Taz responded to my support request in less than 4 hours, so that’s cool. :wink: