My Maya 2015 SP5 seems to be leaking memory (allocating 100mb RAM/s)

[j.qarlsson]

Hello!

I have a certain scene where this is occuring and it starts off good as it should with Maya not using more than around 4-5 gb of RAM. But as soon as I load in a new .dds texture with 1024x1024 resolution and start up the UV texture editor maya starts chomping away roughly 100mb RAM / sec until it has used up all my memory and either crashing the computer entierly or just forcing me to close the application.

Is there anything I can do about this?
It's not producing any crash reports so I can't send one of those..

Please help!

Regards,
Johan

[abogomolov]

The same is for me. 16Gb of memory goes away in a flash during UV mapping.

[j.qarlsson]

For me it happends when I load a new texture in the material and then run the UV editor.
As soon as I open the UV editor and have that new texture display there it starts eating away the memory. And if I close it, it halts and opening it again will return to eating memory.

Maybe it's the same for you?

[syracoj]

hey are all of you experiencing this with a .dds texture or is the common element here the uv editor itself?

Any new information regarding this since you have encountered this issue?

What are your system specs (most notably graphics card and driver version)?

Are you guys managing the uv's via multiple tiles or uv linking?

[PedroXepha]

Hello. This is driving me crazy. I have a simple scene, just a mountain model, no texturing or anything. With this scene opened my sistem has 4 gigs of free memory. Then I simply start surfing the Maya menus, without clicking on anything, and the system runs out of memory and Maya crashes!!!

[rmf001]

No help on this? I am running into a similar issue. RAM usage continues to climb until i max out around 9gigs. Then maya locks up.

Running amd firepro5700 (updated drivers yesterday thinking it might be the problem but its still occuring), 12g ram. Maya 2015 SP5.

[rmf001]

FYI i am using multiple UV sets and DDS textures, with layered textured materials, and with UV linking.

[syracoj]

regarding:

"

FYI i am using multiple UV sets and DDS textures, with layered textured materials, and with UV linking.

"

okay, thats fairly specific. Let me take a look on my side.

back to you in a bit.

[syracoj]

do you guys have the node editor open too?

[rmf001]

No. I never use the node editor.

[syracoj]

So...

I am able to repro the issue on 2015 extension build.

my repro steps were:

create a polySphere at r 10, and sx sy of 50

delete history

did planar mapping Y direction on said sphere

added blinn mat and piped a 1024X1024 .dds texture

disconnected the transparency port which piggy backed the dds txt.

SO FAR: mem okay

opened UV texture editor

SO FAR: mem okay

switched vp2 display to textured

SO FAR: mem okay

opened node editor and loaded I/O of the blinnSG node

MEM STARTS INCREASING (at the time of writing this sentence, mem was at 9gigs and climbing)

NOTE: on an earlier test, I got the mem to climb. But during that test it reached ~8 gigs but then started to reclaim the mem back.

So far on this test, reclamation is not occuring.

Testing on an internal beta build this is no longer occuring but I will run some further tests. Perhaps the candidate that will eventually become the next major release of Maya may have a fix in for this. 

but to sum it up, on the aforementioned 2015 build I AM able to reproduce rogue memory climb. At the time of writing this sentence its still in the high ~9gig range (its bouncing back and forth from 9,100's - 9,700's range in the task monitor.

The interesting component to this though from my testing seems to be the combination of the UV editor AND node editor open. As in it did not occur when the Node Editor was closed.

[syracoj]

hmmm thats interesting if you never use the node editor.

let me grab sp5 explicitly and try there.

which os are you on bye the way?

[rmf001]

Windows 7 pro 64 bit.

I haven't been great at tracking when the memory leak starts, but it seems to end up locking up once I am making/ breaking UV linking connections, adding or changing or reloading textures connected to my layered texture materials, editing UVs etc. I'll try to keep an eye on it today and look for anything noteable. From what I can tell it doesn't seem to climb drastically during any single operation, it just slowly continues to use more and more RAM until its using everything thats available.

[syracoj]

k, let me know what you find.

[rmf001]

Real quickly from what I can tell, is that everytime I create a new UV set (copying or new projection), delete a UV set, reload/ update a texture, or change UV linking, maya begins to eat up another 5-20mbs of RAM, and doesn't seem to ever want to release any of it. I was able to go from ~450mbs to ~700mbs of RAM usage in a just couple minutes by randomly changing UV links, textures, UV sets, etc. Currenly at 694,508K memory, and its sitting steady there. But if I continue to work, mem usage continues to climb. Clearing history, optimizing scene size only increases the memory load. Couple more UV link changes, and Im ~720,000k mem.

[rmf001]

Update... Seems maya doesn't want to release RAM memory at all. No matter what I am doing it just keeps climbing. Usage does not drop until i close maya. Opening or creating a new scene isn't even clearing cache.

[TearlessBoy]

This is happening to me now. Maya is eating 10+ GB of my RAM.

I am not using any .dds texture, I'm just using a .JPG checker texture for working with the UVs, nothing else. This happens while working with the UV Texture Editor.

[syracoj]

So to close the loop on the 'significant' memory leak issue...

so we have drawn up a defect for this issue and will hopefully have a fix returned in the coming future.

for tracking purposes, the defect entry that catalogues this issue is: MAYA-45261

This specific issue is due to the node editor open with the SG and file txt node graphed while the uv editor was open

It is not related specifically to the .dds file format.

In regards to the defect where smaller memory sizes are being used and not reclaimed I will have to continue looking into that. More to follow with regards to that later.

thank you for bringing this to our attention.

for workarounds:

In my personal testing I noticed on my win8 machine on 2015 sp5 that the memory would only start to climb if I had my object selected. If the object was deselected it would quit climbing. 

I also noticed that once I closed the node editor (and possibly the texture editor) the memory would start to reclaim as well.

Additionally, if you edit your SG network (where the file texture resides and is plugged) once your done with your edits, if you navigate out of this network then the memory should discontinue its climb.

Hope this helps guys.

[rmf001]

"In regards to the defect where smaller memory sizes are being used and not reclaimed I will have to continue looking into that. More to follow with regards to that later."

Please do. It does not seem like Maya wants to reclaim any memory at all really. My only workaround for right now is to occasionally close Maya whenever it starts using too much memory and then re-open to start fresh until it climbs again.

Should i attempt to roll back to SP3 or 4? is that even possible?

[syracoj]

rmf001,

regarding:

Please do. It does not seem like Maya wants to reclaim any memory at all really. My only workaround for right now is to occasionally close Maya whenever it starts using too much memory and then re-open to start fresh until it climbs again.

we are fairly swamped this week, so if you dont hear back from me by tuesday regarding this, ping me and I'll look into it then. I will try and get back to it sooner though.

Should i attempt to roll back to SP3 or 4? is that even possible?

I believe you can roll back only if you installed the sp's in succession by just uninstalling the previous patches.

The safer yet more time consuming route would be to uninstall 2015 completely and reinstall 2015 then add the patch you want. But you should probably let me try and find out which maya sp this issue started to occur in. Or, naturally you can wait for a future release.

Looking at the defect logged it appears this issue may have been occuring in sp4 but possibly not sp3. So dont roll back to sp4. I can grab an sp3 and test locally to confirm that its okay to use sp3 if you would like. Let me know.