I recently updated some of my code where Material.SetInt was used, which is now deprecated.
After having updated my code to use the new version Material.SetInteger, Unity started to crash when calling that new function.
I did not test with newer versions, but it happens with 2021.2.19f1.
The weird thing is that Unity will only crash when 3 or more Int ShaderLab properties are used in a shader.
This is the stack trace:
========== OUTPUTTING STACK TRACE ==================
0x00007FF787269267 (Unity) D3D11CommonShader::ApplyGpuProgram
0x00007FF787275875 (Unity) GfxDeviceD3D11Base::SetShadersThreadable
0x00007FF788872C11 (Unity) GfxDeviceWorker::RunCommand
0x00007FF78887D43D (Unity) GfxDeviceWorker::RunExt
0x00007FF78887D558 (Unity) GfxDeviceWorker::RunGfxDeviceWorker
0x00007FF786F877D7 (Unity) Thread::RunThreadWrapper
0x00007FFD2D167034 (KERNEL32) BaseThreadInitThunk
0x00007FFD2D3C2651 (ntdll) RtlUserThreadStart
========== END OF STACKTRACE ===========
I also get that Assertion failed just before the crash:
Assertion failed on expression: ‘(buffer.size() - startSize) <= m_PrepareValuesMaximumBufferSize’
After a while, I realized the reason for the crash is because Int ShaderLab Material Property is also deprecated and backed by a float, rather than by an actual integer.
Therefore, when using Material.SetInteger(), you have to be extra careful to also update your ShaderLab Int properties. Otherwise, mismatching the deprecated ShaderLab Int property with the new SetInteger Material function can crash Unity.
I believe it would be important for Unity to either gracefully handle this situation, or at the very least log an error instead of crashing. A bug report was opened: IN-14562 - Crash when new “Material.SetInteger()” function is used with deprecated “Int” ShaderLab property type
This post was added to document the issue.
