getFileDataAsRegularArray: (function(node) {
if (node.contents && node.contents.subarray) {
var arr = [];
for (var i = 0; i < node.usedBytes; ++i) arr.push(node.contents[i]);
return arr;
}
return node.contents;
}),
getFileDataAsTypedArray: (function(node) {
if (node.contents && node.contents.subarray) return node.contents.subarray(0, node.usedBytes);
// !!!! The line below is the line that the crash happens on. I'm assuming node or node.contents is null
return new Uint8Array(node.contents);
}),
expandFileStorage: (function(node, newCapacity) {
if (node.contents && node.contents.subarray && newCapacity > node.contents.length) {
node.contents = MEMFS.getFileDataAsRegularArray(node);
node.usedBytes = node.contents.length;
}
Anyone know where this code comes from or what is triggering it? I’m assuming its some sort of in memory file system. Is this asset bundle related?
Any help that would point me in the general direction would be greatly appreciated.
I’ll probably just start placing some Debug.Log’s in there and see if I can narrow it down to a particular asset bundle or area of the code
I’ve added additional debug output to the javascript to try and track this down and it seems like it has something to do with loading cached asset bundles. It also seems like it is only an issue with chrome.
Looking at the output in Chrome I get the following
I didn’t manage to track this down and find a solution but turning off exceptions for the WebGL build is an effective workaround. This probably explains why not everyone who is using asset bundles on WebGL is experiencing this. That and maybe it is cause by having certain types on prefabs or objects on the asset bundles.
As a suggestion I’d recommend adding a ‘null check’ to the c++ code that the javascript is generated from (in the function getFileDataAsTypedArray).
I have a very similar problem utilising LoadFromCacheOrDownload and PlayerPrefs.SetFloat.
That is, my assetbundle downloads and appears to work perfectly, but when I attempt to save a player’s audio volume preferences afterward, I get the exact error and stack that you do.
We get this exact error, too, but only in release builds (WebGL Error ‘Uncaught TypeError: Cannot read property ‘length’ of null’).
The development build works fine. We were building with exception handling set to “explicitly thrown only”. Trying it now with exceptions turned completely off…
Tried it with exception handling at all 3 of the options and it makes no difference. We always get this error on release builds, never on development builds.
If I’m able to make a repro project then I will submit a bug report.
Its a while ago since I had this issue but I seem to remember it was a problem with having ‘Data Caching’ turned on in WebGL/PlayerSettings/Publishing Settings. As soon as I turned it off the issue went away. Also seem to remember each browser handling the ‘IDBFS’ storage a little bit differently. Again this was a while ago so maybe its fixed or I’m remembering it incorrectly.
Solved the issue for our game: this was entirely our fault but the error was so opaque that it was hard to find.
We had an obsolete UnityConfig.jsgz and fileloader.jsgz from an earlier Unity version still being linked to from the hosting page. We upload the rest to S3 behind a CloudFront cache, and we invalidate “the things that change” in Cloudfront, but we left those 2 stale files from earlier Unity versions.
Replacing them with current versions from this build fixed the issue and we are now up and running, with no more " Uncaught TypeError: Cannot read property ‘length’ of null" error.
I’ve been having this issue for a week or so. It is happening in a Java Spring Boot application. I tried to dig down in the UnityLoader.js code and it seems to be related to webassembly. Can anyone please help me?
I am getting the same error in a WebGL build, in a project where I do a lot of UnityWebRequestTexture.GetTexture() requests. These requests load tile image textures for a minimap. The error seems to occur when I move through the map very fast, quickly starting/stopping a lot of these web requests.
The idea is that these requests might can be interupted and Disposed, even before completing the download of the tile texture. This works fine most of the time, but sometimes throws that error.