SqliteCache.cpp:609 disk I/O error

Cesium for Unity
1

It is some sort of cache error that ruins performance and spams the console with the error.

I’ve tried everything, from reinstalling the editor, deleting all of Unity’s (and project) internals and starting clean, rebuilt all of Cesium, to trying different Android SDK/NDK versions, nothing worked.

The weird thing is, I’ve used the same Cesium fork with the same commits last week and didn’t have any issues…

Apart from ruined performance, it doesn’t impact the Cesium functionality.

2025/11/21 02:05:28.076 6560 7064 Info Unity [2025-11-21 02:05:28.076] [error] [SqliteCache.cpp:475] disk I/O error
2025/11/21 02:05:28.085 6560 7064 Info Unity [2025-11-21 02:05:28.085] [error] [SqliteCache.cpp:357] disk I/O error
2025/11/21 02:05:28.085 6560 7064 Info Unity [2025-11-21 02:05:28.085] [error]
[SqliteCache.cpp:320] disk I/O error
2025/11/21 02:05:28.085 6560 7064 Info Unity [2025-11-21 02:05:28.085] [error] [SqliteCache.cpp:357] disk I/O error
2025/11/21 02:05:28.085 6560 7064 Info Unity [2025-11-21 02:05:28.085] [error] [SqliteCache.cpp:320] disk I/O error
2025/11/21 02:05:28.120 6560 7064 Info Unity [2025-11-21 02:05:28.120] [error] [SqliteCache.cpp:609] disk I/O error
2025/11/21 02:05:28.120 6560 7064 Info Unity [2025-11-21 02:05:28.120] [error] [SqliteCache.cpp:475] disk I/O error
2025/11/21 02:05:28.262 6560 7064 Info Unity [2025-11-21 02:05:28.262] [error] [SqliteCache.cpp:609] disk I/O error
2025/11/21 02:05:28.263 6560 7064 Info Unity [2025-11-21 02:05:28.263] [error] [SqliteCache.cpp:475] disk I/O error
2025/11/21 02:05:28.263 6560 7064 Info Unity [2025-11-21 02:05:28.263] [error] [SqliteCache.cpp:609] disk I/O error
2025/11/21 02:05:28.263 6560 7064 Info Unity [2025-11-21 02:05:28.263] [error] [SqliteCache.cpp:475] disk I/O error

3

Any help would be greatly appreciated.

4

Sometimes getting:

[deleted due to irrelevancy]

Seems like something somewhere is corrupted, if only I knew what :thinking:

1 Like
5

Hi @Your_RainBoy, I hate to say it, but it’s probably about memory.

The specific source file it’s compiling when it crashes, CesiumPropertyTablePropertyImpl.cpp, takes an unreasonable amount of memory to compile, especially on older versions of Clang. Because you’re running with --parallel 33, your system is compiling that file plus potentially 32 other files at the same time. If those other files happen to hit memory hard too, you’re going to run out of memory and crash. It’s not surprising that it worked previously, because it will be a bit random depending on which files end up being compiled at the same time.

I suggest trying with --parallel 1 and see if that works.

6

Thank you so much!

7

But the only place that it’s not as default is
cmake—build build -j22

Which i’ve now lowered to j12

Where can I find the parallel cmd?

9

I don’t really have enough context here to know what this is about, but could imagine that the attempted workaround was to change the line cesium-unity/Editor/CompileCesiumForUnityNative.cs at 735ac5242718e372739f050e236ea07996f48b04 · CesiumGS/cesium-unity · GitHub to "1".

10

Thank you!

Yeah the memory error only happened once and assumed it was related, but I’m not getting it anymore either way. So it’s more than likely not that.

The console is clean in the editor, but I’m still getting the sqlite cache error spam on Android.

It sometimes lowers FPS to 15-20, where previously >60 was easily reached…

So it’s an urgent issue that needs addressing on my end, I still think it’s a corrupt file somewhere.

Today I started fresh and cloned Cesium 1.9.0 without any added changes, built it as specified in the dev documentation, and the errors were still there in the Android build.

So yeah, reinstalled Unity, tried reinstalling the Android SDK for Android API level 32, deleted the build folders multiple times to ensure it wasn’t just a random bug, and even deleted the entire Library folder in the project.

Let me restate, these sqlite errors weren’t in a previous build just over a week ago.

Any ideas whatsoever would be greatly appreciated:

[SqliteCache.cpp:475] disk I/O error
[SqliteCache.cpp:357] disk I/O error
[SqliteCache.cpp:320] disk I/O error
[SqliteCache.cpp:609] disk I/O error

11

A somewhat helpless guess (until @Kevin_Ring chimes in with more goal-directed hints) could be to find out which SQLite file is actually accessed there, and try to open it with any other SQLite tool (e.g. https://sqlitebrowser.org ), just to see whether it can be opened, or whether it is in fact corrupted (or the disc is actually broken). The next steps would then depend on the outcome of that. (I don’t know these steps in detail, but this might be a step that brings us closer to an answer, with relatively little effort…)

12

Thank you!

Just to clarify, switching to the previous build makes the error go away, so I don’t think the disc is at fault.

I only use GP3DT, no other tilesets are active.

În dum., 23 nov. 2025 la 22:01, Marco13 via Cesium Community <notifications@cesium.discoursemail.com> a scris:

13

Which verison worked, and which one doesn’t? I’m not aware of any changes in that area, but maybe by looking at the two versions I’ll have some ideas.

Typically, a disk I/O error on Android would indicate the APK doesn’t have the necessary permissions to write the SQLite-based request cache. Or the SQLite cache DB on the device could be corrupted I suppose, but that seems less likely.

15

It does sound like perhaps the cache database is corrupt. The cache database location is determined by this code:

I’m honestly not sure offhand where that is on the device. The Unity documentation for Application.temporaryCachePath doesn’t help much:

So I guess I would suggest adding a line to one of your scripts to print out the value of that property, and then run it on the device.

16

2025/11/26 22:57:29.573 22535 22590 Info Unity Application.temporaryCachePath: /storage/emulated/0/Android/data/com.app.name/cache

17

Deleted the entire: Android\data\com.app.name

And the error persists after reinstalling the app.

18

I have removed my fork and used the raw 1.9.0 from the Package Manager just to check, still there!!!?

19

I have finally isolated the problem and I think it should be reproduceable:

  1. Use Unity 2023.1.22f1
  2. Use Cesium 1.9.0
  3. Setup a scene with Bing Maps Cesium World Terrain Tileset (ionAssetID: 1) and G3DPT with API key.
  4. Build for Android → no errors in console via Android logcat
  5. Delete the Cesium World Terrain game object, only leaving the G3DP Tileset with your key.
  6. Build for Android → SQLite cache error spam with each camera turn in console via Android logcat

The interesting part is that I have 2 scenes in my project (Main Menu and the actual experience) if I put the Cesium World Terrain Tileset in the Main Menu scene, and have the main scene itself only using the GP3D Tileset, no other tilesets, the errors ALSO go away when changing the scene…

If you guys have any fixes for this code-wise, I can add them to my fork, otherwise I’m not really sure what can be done Unity-wise; not hacky at least.

Any help would be massively appreciated!!!

20

I know this bug is extremely weird, I’m surprised it’s even possible, but I reproduced it and it is deterministic.

I would like to mention that I’m currently in a hackathon and need to finish the update in a few days, so getting this fixed quickly is crucial @kring . I would appreciate any recommendations regardless of what it takes.

21

This also fixes it:

public class DeleteBingMaps : MonoBehaviour
{
   public Cesium3DTileset spaceGlobe;
   void Start()
   {
      StartCoroutine(Delete());
   }
   IEnumerator Delete()
   {
      yield return null;
      Destroy(spaceGlobe);
      Destroy(this);
   }
}
22

Honestly, I’m at a loss as to how that could happen @Your_RainBoy. v1.9 is quite old, though. Can you reproduce it in the latest releases, too?

23

Same here.

Unfortunately I can’t use newer versions due to severely degraded performance, if my steps above are reproduce-able on your end, feel free to try.