updating Boehm il2cpp garbage collector

Unity Engine
1

Hi there,

I’m hitting an issue (on Unity 2019.1 and Unity 2019.2) where my app will frequently hang with stacks that look something like:

GameAssembly!GC_mark_from+0x3e0 [IL2CPP\external\bdwgc\mark.c @ 860]
GameAssembly!GC_mark_some_inner+0x31c
GameAssembly!GC_mark_some+0x10
GameAssembly!GC_stopped_mark+0x498
GameAssembly!GC_try_to_collect_inner+0x180
GameAssembly!GC_collect_or_expand+0xc4
GameAssembly!GC_alloc_large+0x100
GameAssembly!GC_generic_malloc+0xc8
GameAssembly!GC_malloc_kind_global+0xc8
GameAssembly!GC_malloc_kind+0xe0
GameAssembly!il2cpp::vm::Object::Allocate+0x4
GameAssembly!il2cpp::vm::Array::NewSpecific+0xfc
GameAssembly!Array_Resize_TisTMP_CharacterInfo_t15C146F0B08EE44A63EC777AC32151D061AFFAF1_m67A46DBACBE5D9CB5439A5DCBB29419AF19C1427_gshared+0x7c
GameAssembly!TMP_TextInfo_Resize_TisTMP_CharacterInfo_t15C146F0B08EE44A63EC777AC32151D061AFFAF1_mEAFD11F421C8DF6D85A53E34B31AA0C430CD1143_gshared+0x3a4
GameAssembly!TMP_TextInfo_Resize_TisTMP_CharacterInfo_t15C146F0B08EE44A63EC777AC32151D061AFFAF1_mEAFD11F421C8DF6D85A53E34B31AA0C430CD1143+0x18
GameAssembly!TextMeshPro_SetArraySizes_mFB0E793E5D4BE80318D0F7FB1F605668E352BBFB+0x3814
…etc

It’s not always TextMeshPro further down the stack, really anything that might allocate could be down the stack.
After some research, I’ve found that the implementation of the Boehm GC is a bit out of date. I found a GitHub repro that Unity’s GC seems to be based on. In that repo I found a change in the code path that looked like it might be related to the issue:
https://github.com/ivmai/bdwgc/commit/61e3c072ac3679078e7c43dfe2db03663cef6326#diff-e84d6da61c96ca1a096caf9a494d0d29

I applied this change to my il2cpp project and the problem seems to have gone away. It looks like the issue is to fix a compiler warning. I’m building arm64, and I suspect on this platform the warning raised a valid bug. I’m curious what process unity uses for updating the GC code. I’m likely going to need to patch this until Unity does update, which will be a bit of a pain.

1 Like
2

Impressive tracking this down… I don’t know the answer to your question, but are you using the new Experimental GC? If so, you should probably report your issue as a bug to make sure they know. And if you’re not using the Experimental GC, you could try using that instead of the approach you’re currently taking.

3

You should file a bug report with Unity. I’m sure Unity developers will find your analysis and solution valuable, and save them time getting the fix implemented on their end.

4

The problem occurs if incremental gc is enabled (or not). Is that what you mean by experimental GC?

I want to file a bug report. To do so, I prefer to include a small repro project. So far I’ve not been able to reproduce this outside of my full project, but I’ll keep trying to find the pattern as cycles permit.

edit

Finally I got a repro in my min project. Bug being filed… :slight_smile:

1 Like
5

Hey, could you post a link to your bug report?
I have a similar crash in 2019.4.16 and wonder if it could be the same or if your bug got fixed.
Thanks

6

For anyone stumbling on this, it seems that I resolved my problem by not using callbacks from my native plugin back into c#. In retrospect this makes total sense, the GC system needs to have everything stopped to do its work, al least in the mode I’m using which is the default non-incremental. I would guess that even in the incremental version, having callbacks fire willy-nilly from native into c# would not be a good thing.

Further note of warning: My original code worked fine on a PC build, only crapped out after a while on Android…

7

someone please help on this https://forum.unity.com/threads/crashes-in-lts-2021-3-13.1375125/#post-8677377