Memory leak

[Chatchawind]

I just updated to Corona 13 Hotfix 1 today and encountered the same issue. You're definitely not alone.

In my case, it happened in an old scene that contains many legacy materials. While using  IR Rendering, I adjusted the displacement value in the Material Editor, and suddenly experienced a memory leak. RAM usage spiked to 128 GB, and then 3ds Max crashed.

This seems similar to an issue I encountered in Corona 12 Update 1
https://forum.corona-renderer.com/index.php?topic=44083.0&utm_source=chatgpt.com
https://forum.corona-renderer.com/index.php?topic=43296.msg230075#msg230075, but with a slightly different trigger:

Corona 12 Update 1: The crash occurred while using IR and moving objects in the scene.
Corona 13 Hotfix 1: The crash happened when adjusting displacement settings during IR in a scene with legacy materials.

This issue never occurred with:

Corona 13 (initial release)
Corona 12 Update 2
Corona 12 Update 2 Hotfix 1

My cpu is  AMD Ryzen 9 7950X

Hope this helps narrow things down.

Just like fire and smoke, there is no crash without minidump. Minidump helps more than a reference to an issue.

The issue that Tom calls "apparently excessive memory usage"

When this happens, my PC completely freezes, so I can’t do anything except force-close it. There’s no Autodesk Error Report window after the crash.

We’re on a tight deadline to submit the project, so I don’t have time to troubleshoot further. I’ve decided to downgrade back to Corona 13 (initial release) for now.

Just reporting this in case it might improve or fix the issue in a future hotfix.

Thanks for the advice about the minidump.

[v.p.vlasenko]

Ok, sorry for calling it a memory leak - I was too hasty with that definition.
But as I said something definitely wrong here.

I was trying to see better how the ram is growing so limited render threads to 1 first to slow down things. After that I noticed that each thread use 3-4 Gb RAM. With one it's something like 11-13 Gb, with 2 it can go up to 20Gb and then drop to 15-16 and with 8 it's 32-34Gb. So definitely not possible to render scene using 36 threads. 
Then I decided to check how obviously problematic object will reflect itself and arranged it in a box like structure, without top (5 instanced objects). Glass facing inwards. Put light and camera inside. Now the RAM usage with just 4 threads is 70Gb +/-.

The first and only candidate for problematic object is the one closer to camera - mirror. Due to the way it's modeled. It's a box. "Glass" assigned to 5 faces and backface is mirror + chamfer.
Same problem if two object intersecting, like "glass" box and "mirror" inside of it.

And then a bit of material investigation (legacymtl) - the problem is in glass reflection glossiness (refraction glossiness have no impact). It was set to 0.99. The problem is in range 0.95-0.99+
The higher glossiness value above 0.95 and below 1 - the higher RAM usage and the rendering slowdown, huge.
In recent test I was able to reach almost 100Gb with single thread by using 7 such magical mirrors.

With values like 1 or 0.94 everything working fine with ray depth 100 (difference in RAM between 25 and 100 is negligible, something like 30-70Mb) and the "mirror" IOR 100 or even 999.

So here is the bug as I see it:
highly relfective material (doesn't matter if it's legacy with high IOR or physical set to metal) intersecting or inside of reflective and refractive legacymtl that have reflection glosiness in range 0.95-0.99+ will cause extreme RAM usage and huge rendering slowdown when max ray depth is higher than 50.
And additional problem - you may not be able to cancel it. After some point clicking on cancel doesn't stop the render and max is not responding while memory usage keep growing.

I clicked cancel when usage was 40Gb and after that it was slowly, for probably 30seconds, as I rendered using 1 thread only, growing up to 100Gb and then max crashed.

 

[pokoy]

So the problematic object is a box, so one object with a MultiMaterial assigned? Not different objects for each material?

If this is the case, it could be that the ray optimization engine fails. And if it's the case, what happens if you separate the object into individual planes, does this help?

[James Vella]

huge rendering slowdown when max ray depth is higher than 50.

what happens when you set max ray depth back to default?

[v.p.vlasenko]

So the problematic object is a box, so one object with a MultiMaterial assigned? Not different objects for each material?

In this particular scene - yes, it's a single object, with a MultiMaterial, a kind of real life mirror - backside is reflecive and rest is glass.
If I assign one material, glass or mirror to that object - all good.

But same problem happens with different objects. So, I just cloned that object, assigned glass to 1st, mirror to 2nd, then push modeifier to 2nd, so there is no overlapping faces and moved it back a bit, but those objects still intersecting - same problem with RAM and speed. The real problem is in legacymtl reflection glossiness.

what happens if you separate the object into individual planes, does this help?

Nope, I detached backside mirror surface, then scaled it down and even moved it back a bit - same problem. Check attachment - object on top is single sided glass and plane below is mirror.
Tried to explode surface into faces - same.

So now it looks like this: if ray passing through single sided surface with refractive and reflective legacymtl with reflection glossiness 0.95-0.99 (1) and without exiting media highly reflective surface(material) (2) reflects that ray back to the surface with the same legacytml material (1) - bug. Maybe ray should bounce between those surfaces (1) and (2) - I don't know.

Something like that.

what happens when you set max ray depth back to default?

RAM usage ok, didn't measured speed but visually looks like ok too.

P.S.
To make sure it wasn't a geometry issue - I replaced that "mirror" object with chamfers, which is editable mesh now, by freshly created box and the result is the same.

[TomG]

I don't have any feedback on cause, solution, whether it's a bug or expected etc. sorry - but I didn't want to wait to pop in and say that's some good diagnostic testing and narrowing down of the situation, plus reporting those results, and all that should help investigations into what is happening - thanks!