[Solved] Random exceptions after each build - until EmptyCache-Reload

Unity Engine
1

TLDR: With almost every new version our game website breaks seeminly due to a caching problem with the assembly files. A EmptyCacheHardReload fixes this but this is not something normal users would do.
What can we do to avoid the build from using partially cached code?

Our game is currently live but has a nasty problem (which noone else seems to have according to hours spent on google) where after each new build + upload the website will throw random exceptions while trying to load the game.

Refreshing the page and restarting the browser does not work, the only way to get around this is to do an “Empty cache and Hard Reload” (which works at least for Chrome), after which the exceptions magically disappear and the game loads up fine.

We use a jenkins build process which uploads the files to our webserver in its own, build-date separated, folder, where the DNS resolves the current version as the last serialized version. This happens by un-linking the old version and linking the new one.

The exceptions thrown can be anything ranging from:

  • too much recursion

  • range error - maximum call stack size exceeded

  • index out of range

  • uncaught exception: abort(“Assertion failed: undefined”)

  • Uncaught abort(192)

As along with some or no stacktrace. The errors disappear after the cache-clearing hard reload so these problems are not caused by the programmatic side of the project.

In case relevant, here are some settings used when building
Unity3D

  • v5.6.3p1

Player Settings - Other Settings:

  • Strip Engine Code: True
  • Logging: ScriptOnly, Full Exception

Player Settings - Publishing Settings:

  • Enable Exceptions: Explicitly Thrown Exceptions Only
  • Compression Format: Gzip
  • Name Files As Hashes: False
  • Data Caching: True
  • Debug Symbols: False
  • WebAssembly: False
2

Definitely sounds like a normal browser stale HTTP cache problem. In my opinion the easiest way to avoid it would be to make sure that the WebGL files would be named differently for each build, using hashes filenames, or just a version number.

A more technical approach would be possible if you have a smart reverse proxy in you server, setting correct Cache-Control headers, to make sure that data is cached (and compressed), but that browsers will also ask the proxy always if the file has changed (revalidating). In that case the optimal HTTP “Cache-Control”-header would contain something like “public, max-age: 200000, must-revalidate”

For example Varnish could be configured to do that, but you would also need to make sure that the relevant Varnish caches are emptied during each release.

1 Like
3

Thanks for the good pointers. I assumed it was a frontend issue but if we could solve this in the way our files are served, that would be ideal. We’ll have a go at your suggestions :slight_smile:

4

@KevinGelking
Good if I could help. To be clear, he most simple solution is likely setting this to true:

  • Name Files As Hashes: False => True

If it works, you dont need to mess with a smart HTTP proxy (though I personally would also, as I love Varnish). This should work well, unless the jenkins process somehow renames the files so they wont change across builds.

1 Like
5

For the simplicity and rejection of varnish from our infrastructure dept. we ultimately went for the solution to use the WebGL build option to use hashes for the ‘executable’ filenames.

It was not enough to change the project settings for this as our jenkins pipeline would still spit out regularly named files, but setting it via code (PlayerSettings.WebGL.nameFilesAsHashes) seems to help a bit to weaken the issue. At times the issue does still occur though, unfortunately.

Thanks again for the pointers!

1 Like