Can you only disable the cache till we figure out how to address the issues raised instead of getting rid of the infrastructure necessary for the caches?

In the PersistentCache, avoid initializing the cache_directory_ variable. Also reopen flutter/flutter#14028 with references to the issues this commit caused. I'll investigate and patch the same if you assign the same to me.

Do you have any info on how the cache behaves on the Windows emulators where this problem shows up?

e.g. in Skia's GrGLProgramBuilder::finalize, do the results of glGetProgramBinary look correct? And does the program binary data survive the storage and reloading without corruption?

@chinmaygarde Done.

@jason-simmons I don't have any more detailed info, unfortunately. In general this is a bit of a painful issue to debug since this is windows only and the engine doesn't build on it. I've just been verifying the patches work to fix it by checking to see whether or not apps crash with the stack trace from the bug.

I tried to reproduce the crash but it seems that Skia has made some changes to fix the crash:

On Windows Android simulators, we only get a Program linking failed. error log from Skia instead of a crash if I revert this patch.

I also tried to set GrGLCaps.fProgramBinarySupport = false to enforce the source cache instead of the binary cache. That will make the error go away completely.

I wonder if we shall: (1) revert this patch as is so Skia will use binary cache when possible and emit an error log on Window simulators, or (2) revert this patch and enforce source cache so we don't get any error anywhere.

CC @chinmaygarde