4.6 IL2CPP Memory Crashes

With 4.6.4p1-3 I am getting a new crash - it appears to be memory allocation. I have not encountered this before, it worked fine in 4.6.3p4. It is a significant UI scene but nothing ridiculous. Everything works fine when building with Mono.

I am running on an iPad 3 (32-bit, retina) with a Universal IL2CPP build:
Also crashed with an iPad Air but the memory allocation only shows it getting to 87mb.

iPad 3:
--
i9981(26918,0xd2ef000) malloc: *** mach_vm_map(size=1355776) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

Could not allocate memory: System out of memory!
Trying to allocate: 1354642B with 32 alignment. MemoryLabel: Texture
Allocation happend at: Line:411 in
/Users/builduser/buildslave/unity/build/Runtime/Graphics/Texture2D.cpp

Memory overview
[ ALLOC_DEFAULT ] used: 3550210B | peak: 4241258B | reserved: 3730254B
[ IOS new_delete ] used: 0B | peak: 0B | reserved: 0B
[ ALLOC_GAMEOBJECT ] used: 179270B | peak: 179270B | reserved: 224509B
[ ALLOC_GFX ] used: 4558760B | peak: 6340177B | reserved: 4559273B
[ ALLOC_PROFILER ] used: 2196B | peak: 2232B | reserved: 3355B

Could not allocate memory: System out of memory!
Trying to allocate: 1354642B with 32 alignment. MemoryLabel: Texture
Allocation happend at: Line:411 in

(Filename: Line: 920)
No Texture memory available to upload
UnityEngine.UI.CoroutineTween.<Start>c__Iterator0:Reset()
--

iPad Air:
--
2015-04-20 15:57:38.683 i9981[355:47187] -> registered mono modules 0x102294bd0
-> applicationDidFinishLaunching()
-> applicationDidBecomeActive()
Requesting Resolution: 2048x1536
Renderer: Apple A8X GPU
Vendor: Apple Inc.
Version: OpenGL ES 2.0 Apple A8X GPU - 53.13
GL_OES_depth_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_float GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_vertex_array_object GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_draw_instanced GL_EXT_instanced_arrays GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_pvrtc_sRGB GL_EXT_read_format_bgra GL_EXT_separate_shader_objects GL_EXT_shader_framebuffer_fetch GL_EXT_shader_texture_lod GL_EXT_shadow_samplers GL_EXT_sRGB GL_EXT_texture_filter_anisotropic GL_EXT_texture_rg GL_EXT_texture_storage GL_APPLE_clip_distance GL_APPLE_color_buffer_packed_float GL_APPLE_copy_texture_levels GL_APPLE_framebuffer_multisample GL_APPLE_rgb_422 GL_APPLE_sync GL_APPLE_texture_format_BGRA8888 GL_APPLE_texture_max_level GL_APPLE_texture_packed_float GL_IMG_read_format GL_IMG_texture_comp

ression_pvrtc

Creating OpenGLES2.0 graphics device

Initialize engine version: 4.6.4p3 (b8e48876a626)
UnloadTime: 2.055041 ms
Unloading 5 Unused Serialized files (Serialized files now loaded: 0 / Dirty serialized files: 0)
Unloading 25 unused Assets to reduce memory usage. Loaded Objects now: 1225.
Total: 2.530291 ms (FindLiveObjects: 0.103958 ms CreateObjectMapping: 0.050250 ms MarkObjects: 1.148250 ms DeleteObjects: 1.034666 ms)
i9981(355,0x10caf8000) malloc: *** mach_vm_map(size=1359872) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Could not allocate memory: System out of memory!
Trying to allocate: 1354642B with 32 alignment. MemoryLabel: Texture
Allocation happend at: Line:411 in
Memory overview

[ ALLOC_DEFAULT ] used: 3967809B | peak: 4760737B | reserved: 4155016B
[ IOS new_delete ] used: 0B | peak: 0B | reserved: 0B
[ ALLOC_GAMEOBJECT ] used: 273886B | peak: 273886B | reserved: 319980B
[ ALLOC_GFX ] used: 4908206B | peak: 6814426B | reserved: 4908776B
[ ALLOC_PROFILER ] used: 4176B | peak: 4464B | reserved: 5278B
Could not allocate memory: System out of memory!

Trying to allocate: 1354642B with 32 alignment. MemoryLabel: Texture
Allocation happend at: Line:411 in
(Filename: Line: 920)

i9981(355,0x10caf8000) malloc: *** mach_vm_map(size=1359872) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Could not allocate memory: System out of memory!
Trying to allocate: 1354642B with 32 alignment. MemoryLabel: Texture
Allocation happend at: Line:411 in
Memory overview
[ ALLOC_DEFAULT ] used: 3969857B | peak: 4760737B | reserved: 4157064B
[ IOS new_delete ] used: 0B | peak: 0B | reserved: 0B
[ ALLOC_GAMEOBJECT ] used: 281581B | peak: 281581B | reserved: 329005B
[ ALLOC_GFX ] used: 4450018B | peak: 6814426B | reserved: 4450474B
[ ALLOC_PROFILER ] used: 6696B | peak: 6696B | reserved: 8463B
Could not allocate memory: System out of memory!
Trying to allocate: 1354642B with 32 alignment. MemoryLabel: Texture
Allocation happend at: Line:411 in
Memory overview
[ ALLOC_DEFAULT ] used: 3969857B | peak: 4760737B | reserved: 4157064B
[ IOS new_delete ] used: 0B | peak: 0B | reserved: 0B
[ ALLOC_GAMEOBJECT ] used: 281581B | peak: 281581B | reserved: 329005B
[ ALLOC_GFX ] used: 4450018B | peak: 6814426B | reserved: 4450474B
[ ALLOC_PROFILER ] used: 6696B | peak: 6696B | reserved: 8463B
(Filename: Line: 920)
libc++abi.dylib: terminating with uncaught exception of type CAException

 

I'll see if I can. Is it common for the IL2CPP and/or 64 bit build of iOS to use more memory? The first scene with Mono shows 114MB in Instruments while IL2CPP shows 146MB.

I'm running a few more tests to see if I can watch the memory get too high. But it seems to be an instant crash rather than build up.

 

I removed some resources and now on the Mono build I'm at 67MB and on IL2CPP at 100MB. Still crashes on the next scene for IL2CPP only. My last ditch effort is to put a blank scene in between to make sure memory is flushed and there are no memory spikes.

 

Ok. I'm still crashing and memory doesn't even seem to be high at all before I get System Out of Memory errors. I'm actually crashing in the first scene now only showing 46MB allocated. I'm going to try IL2CPP 32-only as well.

I'll submit a bug shortly.

 

Same thing happens. It crashes the moment I start a simple animation (lerping a single sprite). "error: can't allocate region securely"

 

I have the exact same problem. I tested the whole day to see if something was wrong with the textures and models but the memory impact was really low.

This problem happens since the 4.6.4 version, before was fine but unfortunately I need the 4.6.4 P3 because this version kinda solved some issues I had with T-Net.

Unity 4.6.4p3 using IL2CPP in both 64 and 32 bit. I tested on Ipad3, iPhone 6 plus and iPhone 5. Same problem.

 

Bug report it guys!

 

I've stripped my project down (it was huge) and I can still replicate so I'll finally be submitting a bug here shortly.

 

My project is huge (over 3 gb), I already sent it for another bug report (686082)...do I need to send the project again?
Unfortunately I cannot reduce the size...I tried, no luck.

 

Bug Report finally went thru! Case 691216

 

All done, the case is 691442. Thanks a lot!

 

This is still happening for me in 4.6.4p4.

 

It seems that we have a similar problems, I have a vague assumtion that this is somehow related to render textures.

 

I'm still seeing this in 4.6.5p1. Is everyone else?

 

I still got the problem as well.

 

That's great news, can't wait for a fix! We released the app 2 days ago even with this issue (which is just a part of the app) the client couldn't wait more...

 

Any update on this? On our project we're seeing a 10-35% increase in memory when using IL2CPP rather than Mono with Unity 4.6.5p2.

 

I missed this thread when I made my own post here: http://forum.unity3d.com/threads/ga...-some-other-devices-at-25-250mb-usage.329069/

My issue is 5.0+ related, but it seems to be related to the issues mentioned here.

I get crashes 'due to memory constraints' but my application is not using anywhere near to limit. (25% in our case). I will look in to it again once the update is out and report back. I can't really submit a bug report with our project (it is really big).

 

Am I right in thinking that your change should make it so that the metadata is able to be paged out when not required?

We're seeing higher memory usage with 4.6.4p4 than 4.6.4p3.

These are measurements taken in pretty controlled conditions with identical code, with 13 measurements per build, using a Universal Il2CPP build running on an iPhone 5S built with Xcode 6.3.2. The measurements were taken from the stat shown in Xcode. The Unity profiler shows no change to the size of the ExecutableAndDlls section (but this may not be surprising if it's just a matter of changing how much of that can be paged out).

 

We are using Unity 5.0.2p4 and our project is using about 50-70 MB more memory for IL2CPP builds on iOS than it does with regular Mono 2.x builds. We are seeing memory crashes on high end iOS devices. Are there still improvements for this coming? I'm wondering if there are some problems with render textures as we are using some of those to dynamically create sprite sheets at runtime.

 

I am seeing a very similar crash to what the OP posted, while testing on an iPad 3 running iOS 8.1.3, building from Unity 4.6.5p2 / il2cpp.

XCode is reporting 249.3MB usage from my application, and claims that 568+ MB are free on the device, so the "out of memory" claim is fairly dubious. I can run without problems on an iPhone 6 or an iPad Mini 2, which are also 1GB devices. (FWIW, I crash on an iPad 2 at the moment because we are unfortunately fairly memory tight).

My crash looks like this:

Code (CSharp):

1. spider2(441,0x3c5959dc) malloc: *** mach_vm_map(size=5640192) failed (error code=3)
2. *** error: can't allocate region
3. *** set a breakpoint in malloc_error_break to debug
4. Could not allocate memory: System out of memory!
5. Trying to allocate: 5636080B with 16 alignment. MemoryLabel: String
6. Allocation happend at: Line:74 in
7. Memory overview
8.  
9.  
10. [ ALLOC_DEFAULT ] used: 31792603B | peak: 39491195B | reserved: 35727028B
11.  
12. [ IOS new_delete ] used: 0B | peak: 0B | reserved: 0B
13.  
14. [ ALLOC_GAMEOBJECT ] used: 5044884B | peak: 5919050B | reserved: 6048578B
15.  
16. [ ALLOC_GFX ] used: 6263440B | peak: 23003186B | reserved: 6292377B
17.  
18. [ ALLOC_PROFILER ] used: 32040B | peak: 33012B | reserved: 48950B

It is loading a 5.6MB TextAsset, which is a PNG that I have to load via Resources.Load before turning into a Texture2D because Unity still, absurdly, doesn't have proper native PNG support. While that's a rant for another day, there is a bit of memory pressure in this moment in time because I am loading a bunch of PNGs in a single frame, which means I have to load TextAssets, convert them to Texture2Ds, and then release the TextAssets.

Still, come on, the device reports enough memory for two more instances of the game.

So.... I'm going to try the latest patch release and hope for miracles, and I will also try running a Development build to see if I can get any more info from the Profiler, but if anyone has any further ideas based on my specific case, would love to hear it.

Thanks,
David

 

davekalina while XCode says you are using about 33% of the available device memory, you should note that iOS only lets you use about 40% of the device memory before it will just shut the app down. Apple does this to ensure other processes running behind the scenes will always work.

Unfortunately there is no way for us (developers) to know exactly how much memory we can use but I've found it is usually around 40% of the total as XCode reports it before iOS just terminates the app. For instance, on an iPhone 6 with 1GB of memory our game will usually crash when the memory gets between 400-450Mb. On older devices with 500Mb of memory it will usually crash at about 220Mb (if no other apps are running in the background).

So keep that in mind. XCode is reporting to you about 33% memory usuage but that is actually very close to the limit.

 

Hey Graham,

To reiterate, other 1GB iOS devices do not exhibit this problem and they are running the same game built from the same code. I'm well aware of the fact that iOS devices don't set hard limits on memory you can use. The OP in this thread also is reporting that he is running out of memory on SPECIFIC iOS devices, such as the iPad 3 and the Air.... so, kind of a mystery here, don't you think?

I am seeing other weird S*** on the iPad 3 that I do not observe on other devices. For example, when running a Development build, I get massive leaks and error messages that look like this:

GC Warning: Repeated allocation of very large block (appr. size 3596288):
May lead to memory leak and poor performance.
TextAsset object Hallway_topdown_TMP_SpriteCollection.png / Hallway_topdown_TMP_SpriteCollection: 3592605 Bytes

Memory is bloating significantly over time in XCode here, at least, but NOT in the Unity profiler. Neither the warning nor the memory leaking manifest on other devices, so, uh, WTF?

 

Oh interesting, well that is scary. As I mentioned above we are seeing weird memory bloating with IL2CPP builds on iOS too. It's basically halted all our releases to the AppStore since Apple doesn't allow non-64bit builds on the store anymore and the current memory problems with Unity's 64bit builds make our game too unstable.

I'm hoping Unity has some more memory improvements coming for IL2CPP builds because there doesn't seem to be anything we can do on our end.

 

We're having the same problems, the il2cpp build uses too much memory which makes it very unstable on older devices but we can no longer submit mono builds. It also crashes on 64-bit devices but I haven't managed to track this down yet, will submit a bug report when I can.

 

That's great to hear! We will continue testing on our end to see if we find any specific memory areas to address.

 

That's good news, I'm seeing memory usage of about 20mb more than the mono builds at the moment (e.g. mono was using 150mb, il2cpp is using 172mb)

 

Hi Josh, I see Unity 5.1 is out today. Does that release contain any more memory related fixes for IL2CPP or is it mostly just the fixes from all the 4 patches?

We'll be updating today but I'm just curious if we should expect any memory improvements from patch 4.

 

Thanks Josh, I'm glad I asked then

 

An update based on our project (see above). It looks like 4.6.6p1 saves us about 10MB over 4.5.5p4:



The 4.5.5p4 numbers are different to the previous post as we've done our own optimisations that have saved us about 5 MB.

 

Hi Josh,

Is the 5.1.0p1 release today all caught up with the IL2CPP improvements from yesterday's 5.0.3p1?

Thanks,

 

Im getting a similar issue in 5.1.1. only for some reason its trying to allocate over 1000Mb at once

zodiac(14855,0x199113310) malloc: *** mach_vm_map(size=1058766848) failed (error code=3)

*** error: can't allocate region

*** set a breakpoint in malloc_error_break to debug

Could not allocate memory: System out of memory!

Trying to allocate: 1058750480B with 16 alignment. MemoryLabel: Default

Allocation happend at: Line:81 in

Memory overview


My game does get pretty close the the memory limit on mono but allocating 1058750480B is extreme. I have filed a bug report.

 

Hey @JoshPeterson, regarding @awatson's il2cpp crash case, I managed to some what isolate the memory crash issue, I can't seem to login to FogBugz so I'll post here in the hope it helps you guys resolve it quicker:

The problem occurs when trying to load a custom ScriptableObject type from Resources using Resources.Load<AtlasAsset>(), I'll simplify data types used below:

Code (CSharp):

1. [Serializable]
2. public class AtlasAsset : ScriptableObject
3. {
4.     [SerializeField]
5.     public Atlas atlas;
6. }
7.  
8. [Serializable]
9. public class Atlas
10. {
11.     [SerializeField]
12.     public List<CustomizationSlot> skins;
13.  
14.     [SerializeField]
15.     public List<AtlasPage> pages;
16.  
17.     [SerializeField]
18.     public List<AtlasRegion> regions;
19. }
20.  
21. [Serializable]
22. public class AtlasPage
23. {
24.     public string name;
25.     public Format format;
26.     public TextureFilter minFilter;
27.     public TextureFilter magFilter;
28.     public TextureWrap uWrap;
29.     public TextureWrap vWrap;
30.     public string rendererObject;
31.     public int width;
32.     public int height;
33. }
34.  
35. [Serializable]
36. public class AtlasRegion
37. {
38.     public string name;
39.     public string pageName;
40.     public int x;
41.     public int y;
42.     public int width;
43.     public int height;
44.     public float u;
45.     public float v;
46.     public float u2;
47.     public float v2;
48.     public float offsetX;
49.     public float offsetY;
50.     public int originalWidth;
51.     public int originalHeight;
52.     public int index;
53.     public bool rotate;
54.     public int[] splits;
55.     public int[] pads;
56. }
57.  
58. public enum Format
59. {
60.     Alpha,
61.     Intensity,
62.     LuminanceAlpha,
63.     RGB565,
64.     RGBA4444,
65.     RGB888,
66.     RGBA8888
67. }
68.  
69. public enum TextureFilter
70. {
71.     Nearest,
72.     Linear,
73.     MipMap,
74.     MipMapNearestNearest,
75.     MipMapLinearNearest,
76.     MipMapNearestLinear,
77.     MipMapLinearLinear
78. }
79.  
80. public enum TextureWrap
81. {
82.     MirroredRepeat,
83.     ClampToEdge,
84.     Repeat
85. }

I managed to narrow the crash down to the Atlas class and the three serialised List<T> fields, I thought it may have been the data contained inside so I isolated each field but was still getting the crash. I then tried switching from Lists to fixed arrays and that did the trick, no more crash, so our temp fix is:

Code (CSharp):

1. [Serializable]
2. public class Atlas
3. {
4.     [SerializeField]
5.     public CustomizationSlot[] zodiacSkins;
6.  
7.     [SerializeField]
8.     public AtlasPage[] pages;
9.  
10.     [SerializeField]
11.     public AtlasRegion[] regions;
12. }

I'm guessing but I'd say there is probably a bug with the preallocation of reserved space when using Lists, that may only be present when using ScriptableObjects when loaded from Resources. Hope this info helps, give me a shout if I can be of any assistance.

 

Hey @JoshPeterson I noticed there is now a 5.0.3p3 patch and a 5.1.1p1 release. It looks like the 5.1.1p1 patch is now up to date with all the memory improvements. Is that correct? Should we move over to the 5.1 releases now?