Cura 3.5 memory leak in Monitor

[kmanstudios 1,120]

And, as I went to clean up the crash junk, I found this...after Cura is closed.....

 

 

Cura must be a gremlin, that got fed after Midnight, and then soaked in water because I had closed it out and it has left all these evil little pieces running about.....

 

I see Stripe in there somewhere......

 

[drayson 75]

can confirm - same at my installation(s)

[drayson 75]

can confirm - same at my installation(s)

[ahoeben 1,948]

@drayson please clarify. Same as what?

[ahoeben 1,948]

Today I can reproduce the issue with the camera feed display for OctoPrint. Some pretty weird stuff is going on; for me the memory leak stops when I open the Preferences. Not only does the leaking stop, but I get all my memory back, in a couple of steps. As in: the memory used by the Cura process goes back down.

 

It looks like memory is being released but garbage collection does not kick in until the preferences are opened. I tried opening other windows too, but so far I have not been able to find another window that also releases my memory.

 

Weirder still, I am finding out the memory leak only happens on a freshly started Cura after opening the Preferences window in the first place. It doesn't matter what page either.

 

prerequisites:

* have Cura, OctoPrint and camera feed configured and working

 

steps to reproduce

* start Cura fresh

* go to monitor tab and observe camera

* check memory usage
(in my experience it stays stable)

* open and close the preferences dialog

* check memory usage again
(in my experience it has now starts ballooning)

* wait a couple of minutes and see memory use go up

* open the preferences dialog again
(in my experience the memory usage drops down, in a couple of steps)

[ahoeben 1,948]

It would be good to know if the CuraConnect memory leak also relies on having opened the Preferences dialog.

[oldgojira 0]

I am having the same issues as mentioned above. I will have 5-7 Cura icons in my system tray which will disappear when I go to hover over them.

 

I have a 400mm x 400mm build plate (CR-10 4S) and I am trying to print dungeon pieces from fat dragon games. I find that if I keep the file size ~260mb then it allows me to save my project. However I must have re-created that project a dozen times and tried to save the project and it would take a long time and it would say it was done...but when I went to open the file back up it wouldn't work.

 

I actually upgraded my PC thinking it might be my 7 year old computer but it was not. I now running 32GB of ram, an intel i7-8700K with an nvidia 2080 video card.

[drayson 75]

On 10/22/2018 at 9:53 AM, ahoeben said:

@drayson please clarify. Same as what?

 

Sorry, forgot to quote - not as easy on a smartphone ?

 

This behavior reported by kmanstudios

 

On 10/22/2018 at 9:14 AM, kmanstudios said:

And, as I went to clean up the crash junk, I found this...after Cura is closed.....

 

 

Cura must be a gremlin, that got fed after Midnight, and then soaked in water because I had closed it out and it has left all these evil little pieces running about.....

 

I see Stripe in there somewhere......

 

 

[ahoeben 1,948]

On 10/22/2018 at 9:14 AM, kmanstudios said:

 

 

That is not related to the memory leak. This happens when Cura is not closed down correctly; If Cura crashes, the icon does not get removed. When Cura is then restarted, a new icon is added. It is very untidy (of both Cura and Windows), but not the issue at hand here.

 

PS: sorry to see you had Cura crash on you 11 times.

[kmanstudios 1,120]

2 hours ago, ahoeben said:

PS: sorry to see you had Cura crash on you 11 times.

Kinda think that is a problem with Cura crashing, yes? May not be a memory leak, but it seems to leave pieces behind. and, no, it was not 11 crashes.....it was one crash. So, something is amiss.

[ahoeben 1,948]

If you want this to become another thread about different issues with Cura 3.5, that's fine with me, but then it looses its function to get to the bottom of the particular issue of the memory leak in Cura Connect and OctoPrint.

 

Cura creates one icon in the system tray when it is started. When it is stopped cleanly, it removes the icon. If it crashes, the icon stays there, until you either log out of windows or you happen to mouse over the icon. There is no way that one instance of Cura creates more than one of these icons at a time. The 12 icons in your screenshot mean that Cura closed before cleaning up the icon 11 times since you last logged in to windows. It may not have been a very visible crash, it may have been a fairly silent crash while Cura was closing down. But it was not a clean closing of Cura.

 

Yes, something is amiss, but no, this has nothing to do with the memory leak I am trying to investigate. Thanks for reporting it though.

[kmanstudios 1,120]

7 minutes ago, ahoeben said:

The 12 icons in your screenshot mean that Cura closed before cleaning up the icon 11 times since you last logged in to windows. It may not have been a very visible crash, it may have been a fairly silent crash while Cura was closing down. But it was not a clean closing of Cura.

Well, then, that is a problem, yes? If it only visibly crashes once, but is silently crashing that many times and not even reporting it, then I would say this is an issue.

 

8 minutes ago, ahoeben said:

Yes, something is amiss, but no, this has nothing to do with the memory leak I am trying to investigate. Thanks for reporting it though.

I would agree. But, if it is leaving trash behind, is that not contributing to memory issues? And, since I do not use the onboard monitor, nor octoprint, I am kinda thinking then that this does need to be new thread about 'other' memory issues.

[ahoeben 1,948]

6 minutes ago, kmanstudios said:

But, if it is leaving trash behind, is that not contributing to memory issues?

 

NO

[kmanstudios 1,120]

8 minutes ago, ahoeben said:

 

NO

I see, so, leaving trash behind is not doing anything to clog my system? I guess all that crap left on the HD, reducing virtual memory space means nothing? wow...ok.....I guess it is not an issue to worry about.

[ahoeben 1,948]

This thread has lost its use to me. Bye.

[kmanstudios 1,120]

OK fine. All caps responses did not help. And, I guess us trying to report things that are going awry, I mean, "Silent crashes' and such not being part of the problem is not worth it. OK, nobody is stopping you and really, shows a problem with this process, and it is not the reporting of issues.

[Shadowman 53]

1 hour ago, kmanstudios said:

OK fine. All caps responses did not help. And, I guess us trying to report things that are going awry, I mean, "Silent crashes' and such not being part of the problem is not worth it. OK, nobody is stopping you and really, shows a problem with this process, and it is not the reporting of issues.

Sadly I agree that presenting a problem the best the end user can seems difficult without individuals taking it personally.

 

I know that both you and “ahoben” are trying to assist albeit from different sides of the proverbial table.

 

I hope that cooler heads prevail and that the process to define and resolve remains.

 

Takes care 

[kmanstudios 1,120]

Oddly, whilst presenting memory leaks, of which in my case, did not involve either the monitor or Octoprint, I was dunned and told to place those reports here.

 

So, memory leaks of a general nature go here or there in the regular 3.5 thread. And, I awoke to find out that Cura had crashed overnight. Yeah, I forgot to close it again, but did it crash because it just chewed through memory or what?

 

And, we find out that there is this thing called a 'silent crash' leaving all sorts of bits around to clog the system and has to be manually removed of which clogs the memory of the system.

[StephanFr 0]

In the spirit of trying to get to the bottom of the leak which is where this started, what I have seen - in at least my case - is that memory gets allocated to Cura over time as the monitor runs but if you either minimize Cura or switch to the Prepare view, the memory slowly gets moved over to 'MemCompression'.  It does not actually get released back to the system but it no longer is charged to Cura.  Mem Compression shows up in RAMMap but not in the task manager.

 

My suspicion is that there is leakage probably associated with the video stream and as this memory sits quietly after being leaked, it is scavenged by the MemCompression service and then get charged to that service and not Cura.  If I start a print with Cura and switch back to the monitor, then the memory moves back to Cura from MemCompression.

 

 

 

[kmanstudios 1,120]

1 hour ago, StephanFr said:

in at least my case - is that memory gets allocated to Cura over time as the monitor runs but if you either minimize Cura or switch to the Prepare view, the memory slowly gets moved over to 'MemCompression'.

Just so's you know, in my case, all memory leaks are in Cura prepare and usually when left alone. Minimized and in another application does not matter.

 

I never use the monitor as my machines are right behind me. So, I am thinking that what I have been reporting has nothing to do with video usage or the monitor and I have never used Octoprint.

 

Also, as I stated before, with nothing left on but Cura, but the browser and Cura was minimized, hence why I forgot to close it, it crashed overnight with nothing else going on.

 

Also, to find out that Cura is 'silently crashing' is a real issue for me.

[Brulti 177]

I can confirm that Cura clogs up memory on both Win10 and Win8, even when not launching a print or not going to the 'Prepare' screen.

[kmanstudios 1,120]

Well, since I found out that there are these "Silent crashes", I have taken note that there is not a single time I use the new Cura that it does not close cleanly.

[ahoeben 1,948]

A cause for a memory leak in both OctoPrint Connection plugin and Cura Connect has been identified. I have created a workaround for OctoPrintPlugin. If my workaround works without (too many) sideeffects, it can also be applied to Cura Connect (with some more development work).

 

A testing version of OctoPrintPlugin with the workaround can be downloaded here:
http://files.fieldofview.com/cura/OctoPrintPlugin-v5-2018-10-25T13_58_45Z.curapackage
After downloading, drop the file into a running Cura application and restart Cura.

 

It would be nice to hear if this fixes the memory leak for you when using the OctoPrint Connection plugin. If it does, I will release this version via the Toolbox.

 

NB: the fixed OctoPrintPlugin will not change stability or memory issues with Cura Connect or any other part of Cura, except the OctoPrint integration.

[Adam324 13]

I just did a print sending it to Octoprint and left it on Monitor view and it completed without any memory issues on my system using the new OctoPrintPlugin... curapackage provided in the last post.  I will keep testing but this is the first print that has not caused memory issues on my PC leaving the Monitor window view up.  Initial test looks good so far ?.  Thanks!

[Adam324 13]

After a few prints, It does seem that the big memory leak that occurred within a short amount of time of sending a print to Octoprint (5 to 10 minutes) is gone.  There is still a long running memory leak that occurs in the 'Commit size' memory assigned to Cura but I am uncertain if that has been there before or not (I will have to test 3.4 sometime).  After a few days of it still running, the private memory is at 199MB but the 'Commit size' is 3322MB.  You have to enable the column for 'Commit size' memory in Task Manger under 'Details' tab.  By default it is not shown so you might think it is only using 199MB but in reality it is using 3322MB plus 199MB.  I bet this is why the extreme commit usage over time hasn't been detected yet.

 

Edited October 27, 2018 by Adam324