Search Issue Tracker
By Design
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
- [Quality Hackweek] Activated Terrain Inspector is active only until the terrain GameObject is deselected when two or more Inspectors are open
- Physics Used Memory keeps growing when GameObject colliders are enabled and disabled
- Errors are thrown and Inspector's UI element is not drawing when a GameObject with script component using a List<T> attached is selected
- ConfigurableJoint's parameters are not saved in the Prefab after Runtime Prefab baking
- Popup windows spawn on the incorrect monitor when the Editor is placed near the boundary of scaled monitor next to a monitor with different scaling
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.