Bug Trying to extract a GZipStream in WebGL Release Build crashes the WebGL Player

My game relies on gzips to store player replays.
Reading this gzips in webgl release builds crashes the webgl player.
Minimal Reproducible Example: Add below script to an object

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4. using System.IO;
5. public class Gzipper : MonoBehaviour
6. {
7.     // Start is called before the first frame update
8.     void Start()
9.     {
10.         Debug.Log("Creating Gz");
11.         using (FileStream file = new FileStream("test.gz", FileMode.OpenOrCreate, FileAccess.ReadWrite))
12.         {
13.             using (var gzip = new System.IO.Compression.GZipStream(file, System.IO.Compression.CompressionMode.Compress))
14.             {
15.                 using (var bwMeta = new BinaryWriter(gzip))
16.                 {
17.                     bwMeta.Write("aaa");
18.                 }
19.  
20.             }
21.         }
22.         Debug.Log("Written Gz");
23.         Debug.Log("Creating Mem");
24.  
25.         var masterMemoryStream = new MemoryStream();
26.         Debug.Log("Reading Gz");
27.         using (FileStream file = new FileStream("test.gz", FileMode.Open, FileAccess.Read))//<-- Crashes here I believe########################
28.         {
29.             using (var gzip = new System.IO.Compression.GZipStream(file, System.IO.Compression.CompressionMode.Decompress))
30.             {
31.                 gzip.CopyTo(masterMemoryStream);
32.             }
33.         }
34.         Debug.Log("Read Gz " + masterMemoryStream.Length);
35.  
36.     }
37. }
38.  

On release webgl build I get below error alert in browser

I am using Unity 2022.3.4f1 Apple Silicon Edition
Anyone knows a solution for this?

 

You don't have filesystem access in the WebGL browser which may be the issue here. I'm not sure if "test.gz" gets redirected like File.WriteAllBytes should. Try just FileStream without the Gzip to see if that works.


There is also a storage limit for files in the sandbox, I believe it's 10 MB at most but may be even lower than that.

 

It works in non release builds! In my actual game most of the file based operations are working even in release build, except the above.

 

Oh, in release. My immediate thought is: stripping level. Try building for release with stripping none, in case some code gets stripped out that is being needed but stripping couldn't know that.

 

I solved it by switching to

dotnetzip

 

I have the exact same issue.

 

https://issuetracker.unity3d.com/is...lestream-and-the-file-is-compressed-with-gzip
My first bug report to enter the unity issuetracker.

 

Have the same issue. Please fix asap.

 

Thank you jukka_j for the info.
We just ran into this issue yesterday as well after switching to Unity 2022.3.8. Here are some followup questions:

• Is there a way to control the "Code Optimization" flag programmatically?
• Is it the LTO optimizer that is causing the very large increase in build time? In 2021.3.17 which we used before changing version the build time for release builds was significantly shorter.
• Can we expect the new setting to build without LTO optimization to result in build times comparable to 2021.3.17?

Thanks!

 

Thanks jukka_j. Great info!
It did work to change the Code Optimization like you mentioned.
I am wondering a bit about the resulting application performance if we use "Shorter Build Time" now with 2022.3.8 compared to the "Speed" option which was default in 2021.3.17. Will the application be significantly slower?

 

@jukka_j Thanks very much for looking at it quickly and the speedy workaround! I've been trying to change to dotnetzip, and haven't been able to figure it out, so this might be a quick fix for now. Please let us know when/if the LTO is fixed.I'm assuming it'd be 6 months+, if ever.
Can confirm that faster build is a lot faster. ie about 30 minutes faster for us.

Is 2023 webgl better than 2022 atm? Is it worth upgrading to 2023?

 

Yep, I realise it's not a unity issue. - And thank you so much for figuring it out finding a work around! It really helps a lot.

Is there a a feature list of the upgrades from Webgl 2022 to 2023. I'm having a hard time convincing managers to upgrade to a non LTS version.

 

Not sure if this is helpful:
" If you want to take optimization into the extreme, you can tweak in gcc via --param the costs associated with certain optimizations. Additionally note that gcc now has the ability to put attributes at functions that control optimization settings just for these functions, so when you find you have a problem with -O3 in one function (or want to try out special flags for just that function), you don't need to compile the whole file or even whole project with O2."

https://stackoverflow.com/questions/11546075/is-optimisation-level-o3-dangerous-in-g

Might it be possible to exclude gzip from O3 optimisations ?

 

I wonder if this is why a friend on playing my game gets an "angry red box" and gets the same on her computer (which i find thoroughly unusual) when others dont, but maybe she has even more of a potatoe for equipment than I do.. while I am using 2023.1 i think Im possibly on the fastest not the shortest.. Probllem of course is, being a phone i couldnt get more than angry red box out of her, and the fact her pc didnt run it either really screams something environmental.

 

FYI, I found this bug testing when and where it crashed and then by writing about 30-40 debug.log commands through the code, seeing which ones got called and put more in closer and closer to the line it broke on. I found the line it broke on, rebuild a webgl with just tests on that code, which worked perfectly. So it had to be something before it got to that line. It was in-cased in a gzip extraction, so I searched for that and found this thread. You might need to do something similar to find the root cause of a release only bug.