Hi,
I have a project which I deploy to Steam with the PAK format, under the configuration Win32 Shipping. The content recently just hit 2GB, and I started getting this crash when opening a level:
- If I uncheck “use pak file” in Packaging settings and deploy loose files, the crash doesn’t happen.
- If I also delete some content (it doesn’t matter what) to reduce the pak file size to under 2GB, the crash also doesn’t happen
- If I deploy Windows 64bit Shipping instead, the crash doesn’t happen
I am contemplating deploying loose files to get around this issue, however this is going to be a large, slow update to push out via Steam because of all of the moving around on disk.
Please let me know if I can provide more information.
Alan
Hello AlanEdwardes,
Can you see if this happens in a Development build? If so, could you provide the logs from it? Also, can you provide the logs from the packaging session where you packaged the build that is having this crash? Does this only happen when it’s being launched through Steam or even if you launch the packaged game locally?
Hi Matthew,
This happens if I build for development too.
Startup logs from the Win32 Development build: win32-development-startup.log
Packaging logs for Win32 Development build: win32-development-buildcookrun.log
Steam isn’t a factor, happens when the exe is launched via Steam and directly by double clicking it locally. I am using the launcher version of UE4.15.1, not compiled from source.
Thanks
Just to rule it out completely, I stripped out the steamworks SDK from the build and code, doesn’t seem to be a factor.
It looks like they are crashing differently - here’s a screenshot with the development build on the left, the shipping build on the right:
Logs for the development crash here: [development-insulam.log][2]
Thank you for that information, Alan. From looking at the startup log, I noticed that the assertion and resulting callstack differ from the one you showed in your original post. While the original was an access violation which means that a null reference was referenced, the one in the log points toward IPlatformFilePak.cpp.
Does the callstack differ from Shipping to Development or are you only getting the newer crash now?
Apologies for not picking this up for a while, I haven’t had a lot of time recently. I think I have recreated this with the Elemental demo, on 4.15.1.
I downloaded the project from the launcher, changed it to build for Shipping (and checked “for distribution”).
Targets + results:
- Win32 with PAK: I get a crash on launch
- Win64 with PAK: Demo runs normally
- Win32 with loose files: Demo runs normally
I can’t know for sure if this is the same error as I don’t have debugging symbols for this project, however this correlates with the crash I am experiencing with mine as the PAK file for this project is over 2GB.
Please let me know if I can provide more information here - I had to switch my project on Steam to distribute loose files instead of PAK to unblock development.
Thanks,
Alan
Thank you for the additional information. Despite the delay, we are still looking into this but it may take some more time. I’m glad to see that you at least have a workaround for the moment but we’ll try to get back to you as soon as possible.
I’ve reproduced this using the ElementalDemo and spoke with developers that work in this field. They mention that going past 2GB with a Pak file for 32 bit is expected as the maximum representable integer is way lower on 32 bit compared to 64 bit. This explains why the callstack mentions failing while iterating through.
The only thing I can think to suggest is to either continue using loose files like you are or to attempt using chunks. If you setup and use chunks, it will break the pak file up into chunks and keep the pak file from being one large file and may be able to alleviate this.
OK, that all makes sense, I will continue to distribute loose files for now and investigate chunking.
Going forwards it would be an improvement if the PAK process knew about the limitation and failed the build if any single PAK exceeded the limit - it took me a long time to figure out what this was being caused by, and initially I figured it might have been the content I last added.
Thanks for investigating this.
