Exception on launch in Unity 6000.0.35f1

[NecroticNanite]

Hi!

I recently updated my project to use this plugin. However, on boot of the project, I get an exception.
My project is Unity 6000.0.35f1 for WebGL, using unity-sqlite-net 1.2.0.
I am also reporting to Unity, in case it's a C++ compiler issue.
Removing the SQLite package prevents the issue, but as soon as this package is in the project this will happen on all non-development builds.
The error is actually related to the input system, but only occurs when SQLite is in the project.

Sample project:
Switch to WebGL, then build and run with development mode turned off.
Test Project.zip

Uncaught RuntimeError: unreachable
at Sys_GetNonCryptographicallySecureRandomBytes_m6E685E563363C27974F36F253C28B4F19D9FACF9 (http://localhost:54699/Build/Build.wasm.br:wasm-function[32295]:0xa2f6f9)
at Interop_GetRandomBytes_mCA054362D47D8B1BB32A7501F26A646DD8CA6947 (http://localhost:54699/Build/Build.wasm.br:wasm-function[13422]:0x3c4c5b)
at Guid_NewGuid_m1F4894E8DC089811D6252148AD5858E58D43A7BD (http://localhost:54699/Build/Build.wasm.br:wasm-function[4036]:0x11cd09)
at InputAction__ctor_m2C9BD26403717DAA628B90D4CD2A4057233A1A44 (http://localhost:54699/Build/Build.wasm.br:wasm-function[13610]:0x3d245e)
at RuntimeInvoker_TrueVoid_t4861ACF8F4594C3437BB48B6E56783494B843915(void ()(), MethodInfo const, void*, void**, void*) (http://localhost:54699/Build/Build.wasm.br:wasm-function[76866]:0x13ff1c8)
at il2cpp::vm::Runtime::InvokeWithThrow(MethodInfo const*, void*, void**) (http://localhost:54699/Build/Build.wasm.br:wasm-function[8769]:0x2673df)
at il2cpp::vm::Runtime::Invoke(MethodInfo const*, void*, void**, Il2CppException**) (http://localhost:54699/Build/Build.wasm.br:wasm-function[1874]:0xad01d)
at il2cpp::vm::Runtime::ObjectInitException(Il2CppObject*, Il2CppException**) (http://localhost:54699/Build/Build.wasm.br:wasm-function[26487]:0x87c042)
at il2cpp_runtime_object_init_exception (http://localhost:54699/Build/Build.wasm.br:wasm-function[15777]:0x4ca35b)
at Scripting::RuntimeObjectInitLogException(ScriptingObjectPtr, ScriptingCtorCache*) (http://localhost:54699/Build/Build.wasm.br:wasm-function[3919]:0x117b19)
at ArrayOfManagedObjectsTransferer::iterator::SetupManagedObjectTransferer() (http://localhost:54699/Build/Build.wasm.br:wasm-function[5882]:0x194eb0)
at void Transfer_ManagedObject<StreamedBinaryRead, true>(SerializationCommandArguments const&, RuntimeSerializationCommandInfo&) (http://localhost:54699/Build/Build.wasm.br:wasm-function[46866]:0xe7db30)
at void TransferField_LinearCollection(SerializationCommandArguments const&, RuntimeSerializationCommandInfo&) (http://localhost:54699/Build/Build.wasm.br:wasm-function[14979]:0x455f2f)
at void ExecuteSerializationCommands(SerializationCommandProvider&, StreamedBinaryRead&, GeneralMonoObject const&) (http://localhost:54699/Build/Build.wasm.br:wasm-function[3238]:0xf3269)
at void Transfer_ManagedObject<StreamedBinaryRead, true>(SerializationCommandArguments const&, RuntimeSerializationCommandInfo&) (http://localhost:54699/Build/Build.wasm.br:wasm-function[46866]:0xe7db3c)
at void TransferField_LinearCollection(SerializationCommandArguments const&, RuntimeSerializationCommandInfo&) (http://localhost:54699/Build/Build.wasm.br:wasm-function[14979]:0x455f2f)
at void ExecuteSerializationCommands(core::vector<SerializationCommand, core::allocator<SerializationCommand, 0ul>> const&, StreamedBinaryWrite&, GeneralMonoObject const&) (http://localhost:54699/Build/Build.wasm.br:wasm-function[3018]:0xe7954)
at void TransferScriptingObject(StreamedBinaryRead&, ScriptingObjectPtr, ScriptingClassPtr, SerializationCache::Data*&) (http://localhost:54699/Build/Build.wasm.br:wasm-function[24169]:0x747b66)
at SerializableManagedRefTransfer::Transfer(Object*, SerializableManagedRef&, StreamedBinaryRead&, bool) (http://localhost:54699/Build/Build.wasm.br:wasm-function[33421]:0xa80d50)
at MonoBehaviour::VirtualRedirectTransfer(StreamedBinaryRead&) (http://localhost:54699/Build/Build.wasm.br:wasm-function[88275]:0x15abb0d)
at SerializedFile::ReadObject(long long, ObjectCreationMode, bool, TypeTree const**, bool*, Object&) (http://localhost:54699/Build/Build.wasm.br:wasm-function[33381]:0xa7eaf4)
at PersistentManager::ReadAndActivateObjectThreaded(int, SerializedObjectIdentifier const&, SerializedFile*, bool, bool, PersistentManager::LockFlags) (http://localhost:54699/Build/Build.wasm.br:wasm-function[13009]:0x3a93de)
at PersistentManager::LoadFileCompletelyThreaded(core::basic_string_ref, long long*, int*, int, PersistentManager::LoadFlags, LoadProgress&, PersistentManager::LockFlags) (http://localhost:54699/Build/Build.wasm.br:wasm-function[13010]:0x3a986a)
at RunWebGLPlayer() (http://localhost:54699/Build/Build.wasm.br:wasm-function[34524]:0xaba5cd)
at main (http://localhost:54699/Build/Build.wasm.br:wasm-function[53188]:0x103b03b)
at Module._main (http://localhost:54699/Build/Build.framework.js.br:9:320574)
at callMain (http://localhost:54699/Build/Build.framework.js.br:9:322349)
at doRun (http://localhost:54699/Build/Build.framework.js.br:9:322763)
at run (http://localhost:54699/Build/Build.framework.js.br:9:322935)
at runCaller (http://localhost:54699/Build/Build.framework.js.br:9:322049)
at Object.removeRunDependency (http://localhost:54699/Build/Build.framework.js.br:9:12278)
at http://localhost:54699/Build/Build.framework.js.br:9:3695
at doCallback (http://localhost:54699/Build/Build.framework.js.br:9:70255)
at done (http://localhost:54699/Build/Build.framework.js.br:9:70409)
at Object.reconcile (http://localhost:54699/Build/Build.framework.js.br:9:63682)
at http://localhost:54699/Build/Build.framework.js.br:9:59761
at index.openKeyCursor.onsuccess (http://localhost:54699/Build/Build.framework.js.br:9:61582)

[gilzoide]

Hi @NecroticNanite, thanks for the report.
And thanks for sending a test project, I'll take a look into it.

[gilzoide]

Hey @NecroticNanite , I wasn't able to reproduce the exception.
I just downloaded Unity 6000.0.35 with WebGL support, built the project with development mode turned off. No exceptions at all. I'm using Google Chrome on a macOS.

Anyway, I've seen "unreachable" errors before when I was testing ASYNCIFY in idbvfs (it doesn't use that anymore, it's much better now) and the stack overflowed, maybe you have a similar problem. Did you build with Unity's code optimizations enabled? Maybe with optimizations enabled you get different results.

If using ASYNCIFY specifically, which I'm not sure is the case, you could try changing the ASYNCIFY_STACK_SIZE link option to something bigger than the default (4096).
To change this in Unity, you need to set the PlayerSettings.WebGL.emscriptenArgs from script to -s ASYNCIFY_STACK_SIZE=<big value here in bytes>. Use WebGL Emscripten Settings package to change this directly from the Project Settings, it's a much nicer experience.

Emscripten also has a STACK_SIZE link option, you can try that instead if ASYNCIFY_STACK_SIZE doesn't work. I don't have any more ideas right now, since I cannot reproduce the error.

What is curious is that your exception only occurs on non-development builds, right? So weird 🤔

[NecroticNanite]

Yeah, its a strange one. I'll test on Mac and some different browsers next week, didn't have chance to this week. I'm Chrome on Windows 11. I did try toggling all the various code optimizations and stripping settings with no change. Leave it with me, I'll have another look asap! Thaks for the quick response by the way - Unity is likely to take a couple of weeks to reply to my bug report :)

…

On Sat, 1 Feb 2025, 23:08 Gil Reis, ***@***.***> wrote: Hey @NecroticNanite <https://github.com/NecroticNanite> , I wasn't able to reproduce the exception. I just downloaded Unity 6000.0.35 with WebGL support, built the project with development mode turned off. No exceptions at all. I'm using Google Chrome on a macOS. Anyway, I've seen "unreachable" errors before when I was testing ASYNCIFY in idbvfs (it doesn't use that anymore, it's much better now) and the stack overflowed, maybe you have a similar problem. Did you build with Unity's code optimizations enabled? Maybe with optimizations enabled you get different results. Screenshot.2025-02-01.at.08.48.50.png (view on web) <https://github.com/user-attachments/assets/06ebd76f-a0bf-4c36-a7e7-8c8fee6ce5d0> If using ASYNCIFY specifically, which I'm not sure is the case, you could try changing the ASYNCIFY_STACK_SIZE <https://emscripten.org/docs/tools_reference/settings_reference.html#asyncify-stack-size> link option to something bigger than the default (4096). To change this in Unity, you need to set the PlayerSettings.WebGL.emscriptenArgs from script to -s ASYNCIFY_STACK_SIZE=<big value here in bytes>. Use WebGL Emscripten Settings <https://github.com/gilzoide/unity-webgl-emscripten-settings> package to change this directly from the Project Settings, it's a much nicer experience. Emscripten also has a STACK_SIZE <https://emscripten.org/docs/tools_reference/settings_reference.html#stack-size> link option, you can try that instead if ASYNCIFY_STACK_SIZE doesn't work. I don't have any more ideas right now, since I cannot reproduce the error. What is curious is that your exception only occurs on non-development builds, right? So weird 🤔 — Reply to this email directly, view it on GitHub <#47 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPISQ6LWS37FDSSKPYS7TT2NS2LHAVCNFSM6AAAAABWIUAXBCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMRYHEZDMOBXGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[NecroticNanite]

So some updates here:

• Same crash on Microsoft Edge with my original project settings
• I was using Disk Size with LTO - I hadn't updated that particular setting in my testing (My previous reply I was replying to the email so I didn't see the image - I thought you were referring to C++ compiler settings rather than code optimization - apparently reading emails before bed isn't something I should do). That setting is also not carried over when transferring projects without setting up a build profile, which explains why it worked for you and not for me!
• I just made builds from the original project and the sample project from the previously attached zip without changing settings (the default setting is "Shorter Build Time") and the crash did not occur in the sample project.
• I then built the sample project with Disk Size with LTO and the original project with just Disk Size. Both projects crashed.
• I then tried Runtime Speed and Runtime Speed with LTO - both also crashed
• I then changed both projects to "Shorter Build Time" and neither of them crashed
• Ergo, the only option that doesn't crash on boot is "Shorter Build Time" - this gives me a work around, though for production I'd love to have Disk Size with LTO for performance and smaller downloads.

Best guess is that Emscripten + the bitcode plugin doesn't play nicely with the code optimization settings.

Unity actually no longer recommends bitcode plugins:
"From Emscripten 2.0 onwards, Unity recommends to build Wasm Object File plug-ins that are Wasm object files of type .o, bundled into GNU archive files of type .a"
https://docs.unity3d.com/Manual/webgl-native-plugins-with-emscripten.html

Wonder if it breaks the optimization step?

Also the same page: "Note: When migrating a native plug-in from one Unity version to a version that uses a different version of Emscripten, Unity recommends to recompile the Unity plug-in from source, because the LLVM compiler project doesn’t guarantee binary compatibility of build artifact files across compiler versions."

[gilzoide]

Hey @NecroticNanite , thanks for the additional info. I've been able to reproduce the issue here by building with code optimization enabled (unfortunately Unity 6 is taking like 25 minutes to build this almost empty project in my machine for some reason 🫠).

Best guess is that Emscripten + the bitcode plugin doesn't play nicely with the code optimization settings.

I guess you are right, I tested letting Unity build the native plugin from source instead of using the prebuilt bitcode file and the exception is gone. That was a 1 minute update and another 25 minute build, but at least it fixed the issue in my machine \o/

I removed the bitcode file and changed the import settings for SQLite source files in branch bugfix/unity-6-web, can you please test if it fixes the problem for you?

[NecroticNanite]

Took over 30m for me too! Though that was in my main project rather than the smaller one, and for some reason it always takes ages on my desktop but much faster via CI.

But yes, that does appear to work in my project with Code Optimization set to Disk Size + LTO.

Out of curiosity, what are the knock-on effects of this change?

[gilzoide]

Took over 30m for me too!

And I thought the problem could be my machine, oh my! I realized that Unity is using emscripten built for x86_64 even on arm64 macs, which does take some hit on performance, although I don't know exactly how big is this hit (may be negligible). Thought this could be the problem, but I guess not if you have the same thing (and as far as I know you're using Windows).

for some reason it always takes ages on my desktop but much faster via CI

That's interesting, maybe running in batch mode without visuals is the key for this? Might be a worthy bug report to send to Unity if confirmed.

But yes, that does appear to work in my project with Code Optimization set to Disk Size + LTO.

Success! I'll merge the branch and release a new patch version, thanks for confirming that it works.

Out of curiosity, what are the knock-on effects of this change?

Ok, so let me tell you why I was using the prebuilt bitcode in first place: to be able to set some compilation definitions when building sqlite3.c. On iOS / tvOS / visionOS, Unity lets you add these compile definitions directly in the inspector for the file to be compiled in the native build, but not for WebGL, so I prebuilt the library with them.
With this change, SQLite will now be compiled without any of these flags set, which is not a super problem, but some things are not enabled anymore, like the FTS5, Geopoly, R*Tree and Math functions modules. I don't think many people will use them, but hey, you never know right?
There's an easy fix for this, though, we can actually embed these definitions into sqlite.c itself. You know, that's actually a good idea! I'll try this later this week. In the mean time, feel free to import this package from the bugfix branch if you don't need the additional modules.

[gilzoide]

Hey @NecroticNanite, this fix was just released in the newest version 1.2.2.
Cheers \o/

[NecroticNanite]

Great, thanks! Updating now, don't expect any issues.