Bulk Mesh Prefab migration crashes when Unity UDS shared-memory pool reaches 16 GiB

[sr4dev]

Summary

Migrating several thousand legacy Mesh Prefabs in one Editor session eventually exhausts Unity's internal UDS shared-memory pool and crashes the Editor inside AssetImportManager::ImportInProcess.

This occurred in an anonymous production-scale project. Project names, user paths, and asset names have been removed from the report.

Environment

• Unity-SpriteAssist: 1.5.5
• Unity Editor: 6000.6.0f1
• OS: Windows 11, 64-bit
• Legacy Mesh Prefab candidates: approximately 7,049

Steps to reproduce

1. Open a large project containing several thousand legacy Mesh Prefabs.
2. Run MeshPrefabMigration.MigrateAll().
3. Allow the migration to continue in the same Editor process.
4. After approximately 5,900 prefabs have been processed, the Editor crashes while saving the next prefab.

Observed result

The log reports that Unity's UDS shared-memory pool has reached its exact 16 GiB ceiling:

[Error] Failed to allocate 2644416 bytes - out of memory?
[Warning] Failed to reserve for commiting data of size 2644416
[Error] Cannot extend shared memory: at ceiling 17179869184, need 2644456 more
[Error] Pool pressure: 2644416-byte alloc failed, working set fully live

The asset write then fails:

Import Error Code:(2)
Message: Failed to write the asset file 'Assets/.../Example.prefab'

The native crash stack ends in:

UnityEditor.AssetDatabase:SaveAssetIfDirty
SpriteAssist.MeshPrefabService:UpdateSubAssetsInMeshPrefab (.../MeshPrefabService.cs:65)
SpriteAssist.MeshPrefabMigration:Migrate (string) (.../MeshPrefabMigration.cs:172)
SpriteAssist.MeshPrefabMigration:Migrate (IEnumerable<string>) (.../MeshPrefabMigration.cs:116)
SpriteAssist.MeshPrefabMigration:MigrateAll () (.../MeshPrefabMigration.cs:66)
Unity AssetImportManager::ImportInProcess

Windows Error Reporting records an access violation in Unity.dll:

Exception code: 0xc0000005
Faulting module: Unity.dll

System-resource checks

This was not caused by ordinary system RAM, page-file, or disk exhaustion:

• About 42 GiB of physical RAM remained available.
• Page-file usage was below 0.5 GiB.
• The project drive had more than 600 GiB free.
• Windows reported no resource-exhaustion or disk errors.

The failing prefab was unchanged on disk and matched its Git version byte-for-byte, so it appears to have been the next asset being saved when the UDS ceiling was reached rather than a malformed asset.

Analysis

MeshPrefabService.UpdateSubAssetsInMeshPrefab calls AssetDatabase.SaveAssetIfDirty(meshPrefab) for every migrated prefab. Each save causes a partial refresh/in-process import and commits artifact data into Unity's UDS shared-memory pool.

The existing periodic cleanup:

GC.Collect();
EditorUtility.UnloadUnusedAssetsImmediate();

releases managed and Unity object memory, but it did not release the UDS native shared-memory working set. The pool continued growing until it reached the hard 16 GiB ceiling. Unity then failed the artifact allocation and crashed instead of recovering gracefully.

Restarting the Editor resets the UDS pool, and already migrated prefabs can be skipped, allowing the remaining migration to continue.

Expected result

The entire migration should either complete without exhausting the UDS pool or stop cleanly at a resumable checkpoint before reaching Unity's internal limit.

Suggested mitigation

Possible approaches:

• Process a bounded number of prefabs per Editor session and persist a resume checkpoint.
• Make the migration naturally resumable in smaller batches (for example, 500-1,000 prefabs).
• Warn users to restart the Editor between large batches when the candidate count is high.
• Investigate whether the per-prefab SaveAssetIfDirty / partial-refresh path can be replaced with a strategy that does not keep all UDS artifact data live.

The current MigrateFlushInterval plus UnloadUnusedAssetsImmediate is not sufficient for this UDS limit.