[link text][1]
I’m getting this issue on a 24gb computer but not on a 16gb one, could this be an allocation bug? It’s recurrrent and seems to happen all the time…
125254-outofmemory.txt (4.81 KB)
ShirtyKezRat,
Please try the following [AnswerHub][1] suggestion. If it does not work, please provide me as much information as you can, including any solid reproduction steps you may have.
Thank you!
Project crashes on launch - Platform & Builds - Epic Developer Community Forums
So we tried as suggested on the AnswerHub link you sent me, it still fails all the time. It seems to be failing now on all computers we run the cooking process.
There’s is not much when it comes to reproduction we can send you’re way, we are basically just running a cook, I could look into what kind of options we have. Are the’re any pitfalls regarding map size we should be aware of in regards to memory usage during a cook? Is the’re a set of minimum requirements for cooking or should the cooking process manage to handle high amounts of data without a significant amount of RAM in all circumstances?
We have quite large maps, we are using a script and calling RunUAT with these arguments:
-clientconfig=Development
-serverconfig=Development
-nocompile
-nocompileeditor
-installed
-utf8output
-platform=Win64
-targetplatform=Win64
-build
-cook
-map=%MapsToCook%
-unversionedcookedcontent
-pak
-createreleaseversion=testing
-manifests
-compressed
-stage
-package
-cmdline=
-Messaging
-CrashReporter
-unattended
-clean
Most of which I ripped form the argument list given when doing a cook from within the editor, I will be doing so now.
Any help would be very much appreciated, still cannot figure out what the issue is…
Please delete your Intermediate and Saved folders from your project folder. After you’ve done that, please then try to package again and upload your newest logs. Please also screenshot any packaging settings that you may have, if you’re using the project launcher.
Can you tell me whether or not you’re able to replicate this on a smaller project, or if it’s just yours?
Looking forward to hearing back from you, thanks!
The log I posted in my original post comes from a cook in which we deleted Intermediate and Saved folders.
You have also all the options we are using on the command line above, we have tried different configurations in regards to cooking and all result the same.
Here are our packaging setting again in case:
-clientconfig=Development -serverconfig=Development -nocompile -nocompileeditor -installed -utf8output -platform=Win64 -targetplatform=Win64 -build -cook -map=…ListOfCookedMaps… -unversionedcookedcontent -pak -createreleaseversion=testing -manifests -compressed -stage -package -cmdline= -Messaging -CrashReporter -unattended -clean
We think the problem is in how we set up a particular asset in code, a collegue described this well, I will post in as a reply to this:
"Hi,
currently we have the problem, that cooking of our content always fails with an out-of-memory-exception.
It does not happen, if we remove one single blueprint, which apparently uses a lot of TAssetPtr UPROPERTY members.
Those TAssetPtr are referencing arbitrary actors in arbitrary levels of our singleplayer-world.
To be more specific: We are perhaps cooking an asset that references actors in the majority of our map-data, and perhaps also loads them during cooking, although TAssetPtr seems to exist exactly for avoiding this.
The loading of the TAssetPtr is nowhere triggered in code either, i.e. nobody calls “TAssetPtr::LoadSynchronous”.
They are used only in order to be able to select actors from a dropdown-list, regardless in which level they have been placed, and regardless if the level is a streaming-level or not.
Unreal does not seem to offer another way of letting the pick actors in arbitrary levels on editor-side.
I.e. if we would not be able to use TAssetPtr for this, we would have to use unique-names for every actor, and enter them manually for every actor in a custom FName property-field, which I think is hardly acceptable for populating huge worlds.
Do you have an idea, why using TAssetPtr which reference actors in different maps in one single BP could be a problem during cooking ?
The TAssetPtr seems to be the only suspicious property which could interfere with the garbage collector during cooking.
We also have tried to use the -PartialGC flag without success.
Could anyone give advice how to narrow down the problem further ?
Would it for example be possible to free the TAssetPtr-references at some stage during cooking by registering to a global delegate ?
But why would a TAssetPtr load the object at all during cooking if it is only a string describing the path to the object ?
Or is it possible to exclude this single BP from cooking? I guess this would not be possible, because the cooker needs to know of an asset-dependency-chain at any time?
Thanks for any suggestions"
Could you please provide either a blank project where you’ve gotten this to occur, or provide the code and where you’re putting it in your project so that we can reproduce the issue you’re running in to?
Hey ShirtyKezRat,
We have not heard back from you in a few days, so we are marking this post as Resolved for tracking purposes. If you are still experiencing the issue you reported, please respond to this message with additional information and we will offer further assistance.
Thank you!