This issue has been closed as 'Won't Fix' due to an extended period of time without updates. If this issue is important to you please let us know by posting on the AnswerHub or UDN, and Epic will re-open the ticket for further review.
When a certain kind of mesh is loaded/unloaded at runtime from transitioning levels, the amount of unfreed memory of the game will steadily increase. There is some natural fluctuation of memory but the indicated scenario will continue to grow in size over time; Eventually running the system out of memory.
The specific details of how to construct such a mesh are not 100% concrete, but one factor appears to be importing a model with multiple sub-meshes without "combine meshes" enabled.
The larger the mesh, the faster the memory changes. It is therefore advisable to use a mesh with at least 40,000 tris, but larger meshes may help make the issue more apparent.
Another possible issue which was reported but not verified was that exporting tangents from Max caused a (much smaller) memory leak when "combined meshes" was used.
See related UDN for additional context, project files, memory reports, and blueprint example setup.
Import a model with >40k tris divided across 4-6 non-LoD meshes of 7k-12k tris each. Do not use "Combine Meshes" (uncheck the box during import).
place the imported object in a scene.
Author BP to load the level recursively in a loop (see UDN for screenshot of a BP that does this)
Memory profile the application. DO NOT use in-engine memory reporting. You will need to use an external tool capable of detecting leaks that escape the Engine's notice.
The original crash reports were on iOS devices. It is believed that the iOS is crashing due to its small amount of memory, but is itself not a major factor (it should occur on other operating systems).
There's no existing public thread on this issue, so head over to Questions & Answers just mention UE-41589 in the post.