Application crashes occisonally while loading new Tilesets with Unity 6

[Mercury-Leo]

Our application crashes quite often when loading new Tilesets.
Looking at the logs, it is caused by Cesium.

This used to happen very rarely, but ever since we have updated to Unity 6, this happens a lot.

To Reproduce

I'll be honest, this is hard to reproduce cause I think this happens in very specific scenarios and it won't be easy to redo without our product.

Also important to note:
We are doing this with multiple users that are synced and access cesium-request-cache, sometimes at the same time.

1. Create at least 2 Unity clients that are in the same share server and access the same cache.
2. Move the map between new areas.
3. Zoom in
4. Zoom out
5. Move to a different location
6. Load new Tilesets
7. Crash

Setup

• Unity version: 6000.0.32f1
• Cesium: 1.14.0

Additional context

Whenever the app crashes, it shows the same stack from CreateImplementation.
There are also a bunch of SQL errors which may or may not be related.

0x00007FF90579FB4C (KERNELBASE) RaiseException
0x00007FF867A1488F (CesiumForUnityNative-Runtime) DotNet_CesiumForUnity_CesiumPolygonRasterOverlay_CreateImplementation
0x00007FF866F681A9 (CesiumForUnityNative-Runtime) DotNet_CesiumForUnity_CesiumPolygonRasterOverlay_CreateImplementation
0x00007FF866F65E51 (CesiumForUnityNative-Runtime) DotNet_CesiumForUnity_CesiumPolygonRasterOverlay_CreateImplementation
0x00007FF866EBB997 (CesiumForUnityNative-Runtime) DotNet_CesiumForUnity_CesiumPolygonRasterOverlay_CreateImplementation
0x00007FF866EBB69D (CesiumForUnityNative-Runtime) DotNet_CesiumForUnity_CesiumPolygonRasterOverlay_CreateImplementation
0x00007FF866146799 (CesiumForUnityNative-Runtime) DotNet_CesiumForUnity_CesiumPolygonRasterOverlay_CreateImplementation
0x00007FF8661474FF (CesiumForUnityNative-Runtime) DotNet_CesiumForUnity_CesiumPolygonRasterOverlay_CreateImplementation
0x00007FF8660FE11A (CesiumForUnityNative-Runtime) DotNet_CesiumForUnity_CesiumPolygonRasterOverlay_CreateImplementation
0x000001D89C597684 (Mono JIT Code) (wrapper managed-to-native) CesiumForUnity.Cesium3DTileset:DotNet_CesiumForUnity_Cesium3DTileset_Update (intptr,CesiumForUnity.Cesium3DTileset/ImplementationHandle)
0x000001D89C597533 (Mono JIT Code) CesiumForUnity.Cesium3DTileset:Update ()
0x000001D843FED448 (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr)
0x00007FF882824B7E (mono-2.0-bdwgc) mono_jit_set_domain
0x00007FF88275D204 (mono-2.0-bdwgc) mono_object_get_virtual_method
0x00007FF88275D37C (mono-2.0-bdwgc) mono_runtime_invoke

[kring]

@Mercury-Leo can you please try v1.14.1 and see if it works any better for you? That version includes #536, which should significantly improve the stability on AppDomain reloads.

[Mercury-Leo]

I am on version 1.14.1.
This does happen quite frequently now, when I turn on a tileset (Enabling a Cesium 3D tileset MonoBehehaviour).
There are a lot of tilesets in the scene, and when I enable a very large tileset this happens.

[kring]

Can you help me reproduce this myself @Mercury-Leo?

[Mercury-Leo]

Sorry for the late response.

As I said, this is going to be hard to reproduce.
My best guess is that something on the SQL side is causing this, possibly an IO exception when multiple clients try to access the same local cache on startup.

Hopefully I'll have time this week and try and setup a project to reproduce it.
Maybe if we open multiple instances of the same project that try and access the same tile at the same time I could make this happen.

[kring]

Multiple clients accessing the same request cache can indeed cause "database locked" exceptions. I wonder if the improved exception handling we added in v1.15 could help here? Sorry to keep telling you to upgrade, but we are making incremental improvements that should help with this problem (without knowing exactly what's causing it), and it's good to get a read on whether it's helping at all.

[Mercury-Leo]

@kring
Sorry for yet another late response.
Ever since I've upgraded to 1.15 it doesn't seem to happen anymore.
It hasn't crashed on a tileset in 2 weeks, so it must have fixed whatever was happening there.
Thanks for everything!