FMessageLog leaks memory during runtime when editor systems aren’t available to flush it, the messages persist and can grow to hundreds of megabytes over long enough play sessins.
However I wonder if it should be included in test or shipping builds in the first place. There doesn’t appear to be a way to view them. and it seems that lots of third party plugins and code out there in the wild outputs to message log.
We’re considering stubbing out all calls to message log during runtime but wanted to see what epic does internally with this system.
Can you share more details on your investigation? The FMessageLog class flushes the messages when destroyed. I’m guessing that you have found some classes that might be creating an instance and keeping it alive for the entire process.
Yeah I think there is an instance that exists the entire time during a test build. I think there is a global FMessageLog Instance that is always available. Unsure where its coming from, it seems most references to FMessageLog in unreal’s code gates calls to messagelog via macros, rather than disabling the system outright.
Its not a great solution its not really clear to tools programmers that if you issue an FMessageLog that this is needed.
will try to get some information, need to revert the stubbing on my side to be able to grab it.
That FMessagelog instance should not be leaking. It is created on the stack and will get destroyed (and flushed) when exiting the scope.
The Insights trace could help find the leaking instances. You could obtain the callstacks that accumulate if you did deeper in the tag tree. Make sure you have the “Function(Alloc)” column showing. If the symbols are not resolved, go to the Modules tab and right client on the project exe. This will pop a menu that allows to load the symbols. You can share the trace with the ucache file if you want me to review the allocs that are assigned to the MessageLog tag .