iOS unreproducable crash when working with ArrayList (and mono_gc_out_of_memory)

We have crashes in our Unity iOS app.
We cannot reproduce them when debugging, but we regularly catch this crash.

We tried to analyze crash logs. (crash log is in the bottom of the post)
We examine part of code mentioned in crash log (m_Controller... methods), and cant see something that could cause crash.
We tried to imagine situations that can occurs in that part of code, but see nothing that can lead to crash. There are *small** array of strings which is loadaed from disk, and modified.
We thinking of rewriting this part of code, but we afraid that otherp part of program can affect and lead to this crash, and that crash will remain after rewriting.

We tried to add try-catch block in this part of code and process situation when exception occurs gracefully (move user to our app's main menu), but we have to remove this block due to requirements
to our app.

Also, I think that crash occurs only (or at least much more frequent) in Ad-hoc build (which uses Release configuration in Xcode).
In parts of crash logs you can see mono_gc_out_of_memory in GC_malloc, which is looking very strange to me (I thought that iOS generates memory warning when memory is low, but possibly mono has its own constraints)

Also, there is another one or two crashes in this part of code with different crash logs (without mono_gc_out_of_memory, but ), but **all of them occurs in methods of ArrayList** ( ArrayList.Clear() in other situations).

Can you help us with this situation?
Can you give us any advice please on how should we deal with this crashes?


Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000000e7ffdefe
Crashed Thread: 0

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 MyApp 0x00f0e150 CrashedCheckBellowForHintsWhy() (CrashReporter.mm:73)
1 MyApp 0x00dcd888 m_wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 200
2 MyApp 0x01462eec mono_jit_runtime_invoke + 2152
3 MyApp 0x01504f24 mono_runtime_invoke + 132
4 MyApp 0x015050a8 mono_runtime_delegate_invoke + 128
5 MyApp 0x0150931c call_unhandled_exception_delegate + 340
6 MyApp 0x0150b230 mono_unhandled_exception + 328
7 MyApp 0x01473080 mono_handle_exception_internal + 952
8 MyApp 0x01473918 mono_handle_exception + 64
9 MyApp 0x0148f6d8 mono_arm_throw_exception + 184
10 MyApp 0x00e76ecc throw_exception + 44
11 MyApp 0x014b7f44 mono_gc_out_of_memory + 16
12 MyApp 0x0156a62c GC_generic_malloc + 452
13 MyApp 0x0156a6cc GC_malloc + 140
14 MyApp 0x015045fc mono_array_new_specific + 272
15 MyApp 0x00dd27ac m_wrapper_managed_to_native_object___icall_wrapper_mono_array_new_specific_intptr_int + 68
16 MyApp 0x00b7b2b8 m_System_Collections_ArrayList_InsertRange_int_System_Collections_ICollection + 212
17 MyApp 0x00b7b898 m_System_Collections_ArrayList_AddRange_System_Collections_ICollection + 52
18 MyApp 0x001fc3fc m_Controller_PrepareSkins_string_string_string_string_string_string_string__ + 1600
19 MyApp 0x001fda88 m_Controller_Awake + 4972

 

I *suspect* that the memory size used by Mono is restricted in some fashion, and your code is consuming a lot of it. Do you have a script file with PrepareSkins as a function? You might want to use the built-in profiler, and track what happens with the mono-memory section. Perhaps the amount of memory that the game uses is slowly increasing over time, and it's just bad luck that PrepareSkins happens to want memory and can't get it.

 

Have you actually run this using instruments/analyser in xcode? you'll see a pie chart and a bunch of other stuff as it runs. Watch the console. It's really hard to go over array mem limits if any. I've stored all sorts from giant textures to sounds in them so perhaps that's just the straw that breaks the camel's back.

You can't use all of the device's ram. Half of your minimum spec device is what you should max out at.

 

@Graham Dunnett I will try to look at mono-memory, thank you. There are many places in app with much higher memory consumption, than Prepare Skins, but crashes occurs in PrepareSkins regularly, and doesn't occurs in other places.

 

MSDN says:

So, I guess, if you are calling ArrayList.AddRange in PrepareSkins you potentially are using more than twice the memory needed by the ArrayList as it is copied. If your data structure is large, you might be running out of mono memory during this operation.

 

@Graham Dunned
Our data structure is small.

Behaviour of program looks strange.
We continue to elaborating this issue, we replace all .AddRanges with .Add in foreach, and will test today.