Currently my iPad app crashes in the middle of calling Instantiate. The line it fails on
is this exact line (I have debug output before and after it). I can't replicate the crash on my mac in the editor.
Texture2D restore = UnityEngine.Object.Instantiate(undoData[currentIndex-1]) as Texture2D;
where undoData is an array of Texture2D objects and undoData[currentIndex-1] is not null (I've checked)
I initially thought that this could be to do with memory. I ran the internally iPad profiler which gave:
iPhone Unity internal profiler stats:
cpu-player> min: 7.7 max: 70.8 avg: 16.6
cpu-ogles-drv> min: 1.5 max: 3.0 avg: 1.8
cpu-waits-gpu> min: 0.2 max: 0.4 avg: 0.2
msaa-resolve> min: 0.0 max: 0.0 avg: 0.0
cpu-present> min: 0.5 max: 3.1 avg: 1.2
frametime> min: 30.3 max: 78.4 avg: 37.7
draw-call #> min: 28 max: 28 avg: 28 | batched: 0
tris #> min: 1566 max: 1566 avg: 1566 | batched: 0
verts #> min: 3140 max: 3140 avg: 3140 | batched: 0
player-detail> physx: 1.0 animation: 0.0 culling 0.0 skinning: 0.0 batching: 0.0 render: 1.8 fixed-update-count: 1 .. 4
mono-scripts> update: 13.2 fixedUpdate: 0.0 coroutines: 0.1
mono-memory> used heap: 3194880 allocated heap: 27750400 max number of collections: 0 collection total duration: 0.0
----------------------------------------
As you can see there is plenty of allocated space in the heap.
Is it possible that I have run out of video memory? Is there a way to check this? How could I go about debugging this problem?
Edit:
It definetly is a memory warning. I've been able to find a
WARNING -> applicationDidReceiveMemoryWarning()
message hidden further up above the profiler. This suggests that the used heap / allocated heap values don't reflect the full story and can't really be trusted :/
Update:
Problem solved - but why?
This problem was indeed caused by a memory leak. When replacing the texture on the material, I did not destroy the previous texture, which resulted in the replaced texture remaining in memory.
By calling:
Destroy( renderer.material.GetTexture ("_Texture2") );
before the replacement of the texture:
renderer.material.SetTexture("_Texture2", newTex);
Note that a memory warning was not always produced by the internal profiler.
I still don't understand why this occurs? Shouldn't the memory be collected by the garbage collecter once there are no references pointing to the old texture? Forcing GC.Collect() doesn't work either.
