# Crash on PS4 due to semaphore count with Unity 2020.3.12f1

**URL:** <https://qa.fmod.com/t/crash-on-ps4-due-to-semaphore-count-with-unity-2020-3-12f1/17427>\
**Category:** Unity\
**Created:** [July 13, 2021, 10:32am UTC](https://qa.fmod.com/t/crash-on-ps4-due-to-semaphore-count-with-unity-2020-3-12f1/17427 "2021-07-13T10:32:18Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Robertk92](https://avatars.discourse-cdn.com/v4/letter/r/97f17d/32.png) [@Robertk92](https://qa.fmod.com/u/Robertk92)\
**Post date:** [July 13, 2021, 10:32am UTC](https://qa.fmod.com/t/crash-on-ps4-due-to-semaphore-count-with-unity-2020-3-12f1/17427/1 "2021-07-13T10:32:18Z")

</div>

We have recently upgraded from Unity 2019.3 to 2020.3.12f1, this caused our game to crash on PS4.

The crash is caused by frequent calls to the EventInstance’s EVENT\_CALLBACK.

Unity dev quote:

> The problem is as follows: When a function call is made from native to managed, and if the call is made by a thread that is unknown to the managed VM, the following happens:
> 
> 1. The managed VM thinks _“This thread is not one of mine”_ and must quickly instantiate a new _System.Threading.Thread_ object to represent the calling thread. This is the _ScopedThreadAttacher_ that you can see in the callstack.
> 2. The native representation of a _System.Threading.Thread_ holds a native semaphore as a member variable. This is the _baselibReentrantLock_ that you can see in the callstack, ending up as a _BaseLib\_SystemSemaphore\_Create_ call.
> 3. After the managed call completes, the newly-created Thread instance immediately becomes eligible for garbage collection, but it has not been finalized yet.
> 4. The native representation of the Thread stays alive until the finalizer of the managed Thread is run, after garbage collection.
> 5. If the same native thread subsequently makes another managed call, then _another_ System.Threading.Thread instance is created, including another native representation, including another semaphore.
> 
> So if the native plugin makes calls back into managed code at a very very high rate, then there’s a possibility of hitting any platform limits on the number of concurrent semaphores. On PlayStation 4 the limit on the number of synchronization objects (combined mutexes, semaphores, etc.) is _relatively_ low at [4096]  
> End quote

I have confirmed that this is indeed the issue. In the previous version of unity, the kernel semaphore count remained at around 81 and did not scale with the event instance callback. In Unity 2020.3.12f1 the semaphore count scales exactly with the amount of calls to that callback and the crash happens at around the 3600th call (including mutexes that takes us above the limit).

Even if the callback is completely empty the crash still occurs but if we do not subscribe to the callback the semaphore count remains low and the crash does not occur.

Even though this is probably a Unity-issue, is there a way for FMOD to support the callback in a way that bypasses the logic described earlier?

(it is not an option to run FMOD synchronously on PS4 since this adds too much CPU overhead, even though this fixes the crash).

Kind Regards,

Robert

---

<div class="post-metadata">

**Author:** ![cameron-fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/cameron-fmod/32/261_2.png) [@cameron-fmod](https://qa.fmod.com/u/cameron-fmod)\
**Post date:** [July 22, 2021, 5:30am UTC](https://qa.fmod.com/t/crash-on-ps4-due-to-semaphore-count-with-unity-2020-3-12f1/17427/2 "2021-07-22T05:30:42Z")

</div>

Unfortunately this does look like more of an issue with Unity and there isn’t a lot we can do to work around this as we don’t have access to.

You could try limiting the the callbacks by being more specific with the masks when setting the callback. If it’s beat or marker callbacks you could use the deferred flag which will push them to the main thread.

---

<div class="post-metadata">

**Author:** ![Robertk92](https://avatars.discourse-cdn.com/v4/letter/r/97f17d/32.png) [@Robertk92](https://qa.fmod.com/u/Robertk92)\
**Post date:** [July 22, 2021, 5:43pm UTC](https://qa.fmod.com/t/crash-on-ps4-due-to-semaphore-count-with-unity-2020-3-12f1/17427/3 "2021-07-22T17:43:19Z")

</div>

Thanks for your response!  
We are already using the FMOD.Studio.INITFLAGS.DEFERRED\_CALLBACKS flags, or is that not the one you mean?

Also, I understand you can’t fix this, I have submitted a Unity bug report.

---

<div class="post-metadata">

**Author:** ![cameron-fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/cameron-fmod/32/261_2.png) [@cameron-fmod](https://qa.fmod.com/u/cameron-fmod)\
**Post date:** [July 23, 2021, 4:17am UTC](https://qa.fmod.com/t/crash-on-ps4-due-to-semaphore-count-with-unity-2020-3-12f1/17427/4 "2021-07-23T04:17:57Z")

</div>

That is the flag I was referring to, although we only support deferred marker and beat callbacks so all the others will still fire from native threads.

---

<div class="post-metadata">

**Author:** ![Robertk92](https://avatars.discourse-cdn.com/v4/letter/r/97f17d/32.png) [@Robertk92](https://qa.fmod.com/u/Robertk92)\
**Post date:** [August 17, 2023, 11:40am UTC](https://qa.fmod.com/t/crash-on-ps4-due-to-semaphore-count-with-unity-2020-3-12f1/17427/5 "2023-08-17T11:40:47Z")

</div>

Hi,

Little update on this issue, I posted a bug report to Unity and this was the response:

[https://fogbugz.unity3d.com/default.asp?1352609\_lpru35oc778tskhm](https://fogbugz.unity3d.com/default.asp?1352609_lpru35oc778tskhm)

---

<div class="post-metadata">

**Author:** ![cameron-fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/cameron-fmod/32/261_2.png) [@cameron-fmod](https://qa.fmod.com/u/cameron-fmod)\
**Post date:** [August 25, 2023, 6:15am UTC](https://qa.fmod.com/t/crash-on-ps4-due-to-semaphore-count-with-unity-2020-3-12f1/17427/6 "2023-08-25T06:15:22Z")

</div>

Thanks for the update, it’s unfortunate that they aren’t doing anything about it but at least we know and have a response from Unity.
