Search Issue Tracker
By Design
By Design in 6000.4.X
Votes
5
Found in
6000.0.50f1
6000.2.0b2
6000.3.0a1
6000.4.0a1
Issue ID
UUM-108694
Regression
Yes
Crash on DynamicHeapAllocator::CreateTLSFBlock when opening a specific project
Reproduction steps:
1. Open the attached project "CrashRepro"
Expected result: Project opens
Actual result: Editor crashes
Reproducible with: 6000.0.0b16, 6000.0.50f1, 6000.1.0f1, 6000.2.0b2
Not reproducible with: 2022.3.62f1, 6000.0.0b15
Reproducible on: Windows 11
Not reproducible on: macOS 15.3.2 Sequoia (Intel)
First few lines of stack trace:
{noformat}0x00007FFCB1B6EE2B (Unity) DynamicHeapAllocator::CreateTLSFBlock
0x00007FFCB1B6D733 (Unity) DynamicHeapAllocator::Allocate
0x00007FFCB1B7C765 (Unity) DualThreadAllocator<DynamicHeapAllocator>::Allocate
0x00007FFCB1B6DE8D (Unity) MemoryManager::Allocate
0x00007FFCB1B7883E (Unity) malloc_internal{noformat}
Comments (1)
-
FixItFelix
Sep 04, 2025 09:02
The release notes mention GPU Resident Drawer: Crash on DynamicHeapAllocator::CreateTLSFBlock when opening a specific project (UUM-108694) but I think this has nothing to do with the Resident Drawer.
Our project is not using it but still gets a significant crash rate with this stracktrace.
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- [Android][iOS][UnityPlayerActivity] Legacy InputField.onEndEdit is not called when ending text edit
- Transform corruption and/or crash on PhysX::CreateCharacterController when spawning physics objects into Prefab stages
- UNITY_EDITOR data is Serialized into AssetBundle when building on the active Build Target
- "TLS Allocator ALLOC_TEMP_TLS, underlying allocator ALLOC_TEMP_MAIN has unfreed allocations..." error when changing the Packages "Cache Location" folder
- CompilationPipeline.assemblyCompilationFinished() hangs unity when reloading domain
Resolution Note:
In order to get your project working, do the following to reset to the default value (16mb)
In the ProjectSettings folder, remove the boot config file (or remove the main thread allocator 160MB setting)
In the same folder, open MemorySettings.asset and set the m_MainAllocatorBlockSize to -1.
Next time you open the project, the default value will be used and works fine.
That leaves the question to why you increased the value in the first place? Is there a particular reason in doing so and if so, please let us know.
Some background details on why the allocation is failing: The value represents the amount of continuous memory the allocator uses when expanding its buffers. In this case, the main allocator use this value disregarding what the underlying allocator (tlsf) is asking for, for the specific size bucket granularity. Eventually, on windows, VirtualAlloc will fail not being able to deliver the amount on the specific address. There are workarounds for this, but at the moment this is not supported by our internal virtual allocators. This will be looked into as we are currently overhauling the memory allocation as a whole.
Resolution Note (6000.4.X):
In order to get your project working, do the following to reset to the default value (16mb)
In the ProjectSettings folder, remove the boot config file (or remove the main thread allocator 160MB setting)
In the same folder, open MemorySettings.asset and set the m_MainAllocatorBlockSize to -1.
Next time you open the project, the default value will be used and works fine.
That leaves the question to why you increased the value in the first place? Is there a particular reason in doing so and if so, please let us know.
Some background details on why the allocation is failing: The value represents the amount of continuous memory the allocator uses when expanding its buffers. In this case, the main allocator use this value disregarding what the underlying allocator (tlsf) is asking for, for the specific size bucket granularity. Eventually, on windows, VirtualAlloc will fail not being able to deliver the amount on the specific address. There are workarounds for this, but at the moment this is not supported by our internal virtual allocators. This will be looked into as we are currently overhauling the memory allocation as a whole.