Last week I reported this issue. but I didnt find a good way to reproduce at that time. Since no one keep watching that thread, I have to open a new one.
The problem is ,when I use Meshrenderer.material.setxxx(id,value) with new BatchRendererGroup , there is a probability of crashing
using System;
using System.Collections.Generic;
using Unity.Jobs;
using UnityEngine;
using UnityEngine.Rendering;
using Random = UnityEngine.Random;
public class test : MonoBehaviour
{
public GameObject cube;
private List<MeshRenderer> mrs;
private const int cap = 5000;
private int id = Shader.PropertyToID("_BaseColor");
private MaterialPropertyBlock mpb;
private BatchRendererGroup m_BatchRendererGroup;
void Start()
{
m_BatchRendererGroup = new BatchRendererGroup(OnPerformCulling, IntPtr.Zero);
mpb = new MaterialPropertyBlock();
mrs = new List<MeshRenderer>(cap);
for (int i = 0; i < cap; i++)
{
var obj = Instantiate(cube,transform);
obj.transform.position = cube.transform.position + new Vector3(Random.Range(-5f, 5f),Random.Range(-5f, 5f), Random.Range(-5f, 5f));
mrs.Add(obj.GetComponent<MeshRenderer>());
}
}
// Update is called once per frame
void Update()
{
for (int i = 0; i < cap; i++)
{
var mr = mrs[i];
// mr.GetPropertyBlock(mpb);
var randColor = new Color(Random.value,Random.value,Random.value);
mr.material.SetColor(id,randColor);
// mpb.SetColor(id,randColor);
// mr.SetPropertyBlock(mpb);
}
}
public JobHandle OnPerformCulling(BatchRendererGroup rendererGroup, BatchCullingContext cullingContext, BatchCullingOutput cullingOutput, IntPtr userContext)
{
return new JobHandle();
}
}
Try the code above, build with a development build( higher probability to crash) , apk will first freeze in a while, and then with memory increased ,it will finally crash.
Use mpb instead can avoid crash (however if you keep create new MaterialPropertyBlock,there is still a chance to crash),
I wonder if change material with brg is allowed? if not ,what should I do? if it is a bug,Please fix it asap, Thx.
No, no Materail registered with the BRG. My test case shows that only new BatchRendererGroup(OnPerformCulling, IntPtr.Zero) is enough. Add detail logic like register mat or fill OnPerformCulling function does not make any difference.
When I dispose BatchRendererGroup or dont add BatchRendererGroup at all. no crash.
My test platform is android and ios, both crashed. pc is ok for now.
Another hint is , if I keep dispose BatchRendererGroup and recreate it in Update(), crash disappeared. So I doubt if there is some unexcepted memory access?
When you observe the crash on Android, do you see something like this in your logcat output?
D/Unity: Could not allocate memory: System out of memory!
Trying to allocate: 1073741824B with 16 alignment. MemoryLabel: DynamicArray
Specifically, “trying to allocate” with some ridiculously large number.
If yes, then this looks like it’s another appearance of an ARM specific bug in an internal software component, which BRG happens to use in its implementation.
After more investigation, I think it seems very likely this is caused by an ARM specific internal bug which causes a threading race condition. I have forwarded the bug to the appropriate team.
Unfortunately there doesn’t seem to be anything specific to this error in the log, but your earlier callstack from the other thread fully matches what I would expect from the error I suspect this to be, so I think it’s very likely your issue is caused by that.
OK, Thank you for the reply. Wonder when will this bug be fixed? Is there a plan for this issue in the future release? Anyway, if the bug is fixed, please inform me here, thx.
It seems we got the same out-of-memory crash. https://forum.unity.com/threads/unity-2022-3-5f1-batchrenderergroup-fatal-out-of-memory-crash-on-android.1528546/
It’s very easy for me to reproduce this crash.
Literally you can reproduce it by adding Entities.Graphics to any project.
Then build an Android app, run it, wait 30 seconds, if not crashing, kill the process and re-run it.
It could crash with about 5% chance. All 2022 LTS version could occur.
I encountered a similar issue when I tested with the official sample “boids”. After running more than ten minutes, I received a “System out of memory” error in the log
and it was clearly a low memory kill event.