Memory leak with Cura 3.5.1

[grizewald]

I don't know if it's the plugin or Cura which is at fault, but as I only see this when using the plugin, I'll start here.

If I print a model to my OctoPrint server, everything works fine except for the fact that memory is leaking at a rate of knots when the monitor tab is open with video streaming from the Pi, eventually leading to a locked up computer. Switching back to the prepare tab stops memory usage growing.

I'm running the Cura 3.5.1 AppImage on Linux Mint and talking to an up to date OctoPi. The plugin reports version 3.5.1 as well.

[fieldOfView]

Thanks for the report. There's an ongoing investigation in the Ultimaker forum as well:
https://community.ultimaker.com/topic/24900-cura-35-memory-leak-in-monitor/

Because the memory usage increases so quickly, the camera feed is - to me - the most likely candidate for causing the leak. Unfortunately I just found out that the "Show webcam image" checkbox is broken in this release (and the stream is always shown).

We can still test the hypothesis of the camera feed leading to the memory leak. In the OctoPrint settings, on the Webcam & Timelapse tab, could you clear the Stream URL field? Then restart Cura and check if the memory leak still happens. I know this is in no way a solution, but it is a temporary test to diagnose the issue.

[nallath]

Oddly enough; I don't have the memory leak on fedora (although granted, I do use the UM3 plugin and not the octoprint one).

[grizewald]

I'll give disabling the video stream on OctoPrint a try this evening when I'm home from work. I'd agree with your suspicion that the video feed is the culprit given that the memory usage rises so quickly.

[fieldOfView]

Oddly enough; I don't have the memory leak on fedora

Neither do I, on Windows 10. It could be that we're both running Cura from source; I've had a different bug that manifested only when the plugin was installed through the Toolbox, because of the order in which plugins are loaded. But that's just guesswork, until I do more testing.

[grizewald]

Bizarre.

I tried to reproduce the problem and it seems to have cured itself! I tried monitoring a print job both with and without video enabled and there was no sign of a runaway memory leak.

Sure, Cura leaks just over 1K of memory each time I switch between the "Prepare" and "Monitor" tabs, but that's hardly a big deal.

I don't see any OS updates which came in recently which would affect this, so I'm really puzzled. As a programmer myself, I don't mind bugs, but I really hate bugs which won't show themselves while someone is watching!

I'll try some more tests later, but if I can't make it happen again, I'll close this.

[fieldOfView]

Oh, it is one of those issues...

Ofcourse I still want to get it fixed, so I’ll keep trying to reproduce it. Do let me know if you have any more insights please.

[fieldOfView]

I have found reliable steps to reproduce. This is a first step to getting this fixed, though I am currently somewhat dumbfounded by what's going on. It depends on opening the Preferences window.

prerequisites:

• have Cura, OctoPrint and camera feed configured and working

steps to reproduce

• (re-)start Cura
• 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)

[fieldOfView]

(sorry for the double post, github is having issues)

[grizewald]

Great find! Nice to know I wasn't dreaming.

My printer died this weekend with a power supply issue, so I wasn't able to do anything more trying to reproduce this.

[DuckY1987]

@fieldOfView I didn't open anything, i had just the Monitor Tab constantly open. I had the feeling when i sent my computer to suspend after waking up, this issue happened more often as i switched from stucked camera stream back to prepare and then back to monitor tab. Sometimes i deleted the model and checked the layer view of a new part to print later and switched then back to monitor tab to see the stream of the cam while i do some de# fusion.

Just as a note: i never opened the preferences dialog in any case. Probably any action causes this memory leak? :-( i try more options now, as i have another print running.

[fieldOfView]

You must have gone into the preference at some point, because that's where you configure the OctoPrint plugin. "Manage printers" opens the preferences window, and I think "Add a printer" does too.

[DuckY1987]

Nope, definetely not, i just removed the previous print and added another one, i sliced this and voila it happened again when i switched to another application with open monitor tab.

[danielschafer]

I'm having the same problem.
Did a print over night. Everything was fine.
Started a new print this morning, without restarting Cura. And I run out of memory.
BTW this is on the latest Mac OS version.

[Razwer]

Also adding myself to the list of people who has this issue. I was silly enough to email fieldOfView directly instead of checking github first :(

[tenpaiyomi]

+1 on this as well. Windows 10, 16GB of RAM, i7 8700, and leaving Cura open for an extended period of time after starting a print will bring my whole system crawling eventually.

If there is anything I can send or do to help, feel free to ask.

[fieldOfView]

You can try to see if the reproduction steps I posted above work, and if the memory use goes down again by opening the Preferences window.

[Razwer]

i did open the preferences window just now and i see the memory creeping up slowly. but not sure if that coincides with each other.
Last memory leak was apx 20 mins before i emailed you and cura has been running since. I would expect a crash in the next hour or so. Even without opening the properties window.

Opening preferences again doesn't make the memory go down either :(

Edit. It just went from 688mb to 1100 mb very quickly (within the time it took me to write this post). I opened the preferences window again and it dropped back to 688mb.

[tenpaiyomi]

@fieldOfView So, I opened cura, went to the monitor tab and then clicked <Active Printer> -> Manage Printers to open the preferences dialog. From there I noticed no creep.

Next, I repeated the steps, and then click from printers to materials within the preferences dialog. I noticed a slow bump up in memory usage, but it then seemed to stabilize and go back down, hovering within approximately 2-3MB of usage, but then as writing this I noticed that it hit a point where it then started to climb up, albeit at a very slow rate.

From there, I again clicked on <Active Printer> -> Manage Printers. The memory usage stabilized while the preferences dialog was open, hanging roughly at a constant memory usage, almost static, but not going down. Upon closing the preferences dialog, I again saw a slight bump up in memory usage, but incredibly minor (0.1-0.3MB). The increase continued at this rate, very slowly.

From there, I clicked on Preferences -> Configure Cura. Again, the memory usage stabilized to an almost static point. From there I clicked through all of the preference options, then closed the preferences dialog. From there I left it on the monitor page and went about my tasks. Checking back later, I noticed that the file usage had continued to increase, seemingly accelerating more as time went along. Where prior the increase was generally fractions of an MB over a minute, the rate now was several MB within a minute, and seemingly increasing rapidly. Over the next ~5 minutes, the memory usage had ballooned from ~250MB to 1.5GB, and was increasing at a rate of a few hundred MB per minute.

Again, I opened the preferences dialog from <Active Printer> -> Manage Printers and the memory usage dropped down to ~180MB. I then closed the preferences dialog.

This was approximately 11:11 AM.
At 11:16AM, the memory usage was ~250MB.
At 11:21 AM, the memory usage was ~2.1GB.

[Razwer]

update on my situation: My laptop started to get slow so i checked the memory usage. 15gb ram in use by Cura. I opened the preferences window, BOOM, down to 400mb and then a hop to 950mb. Now while typing this post it creeps up again (1.8gb).
Opened preferences again, drop to 950mb again.

edit. it creeped up again, 1.8gb. did the preferences trick again it dropped again, but now to 1gb

edit2: it keeps creeping up now and it's basically resettable by opening the preferences window but it keeps creeping up once it's closed.

[Thisismydigitalself]

Happened to me last night with Cura351/Octoprint/webcam/win10/64/16GB. during a long print my PC slowed down to a crawl and to the point where it practically froze. I didn't try to debug it. will do so next time - hopfully I won't have to.

[Razwer]

I noticed that when i change tabs between "prepare" and "monitor" very briefly a settings change window pops op and vanishes. This makes me think it's a Cura bug and not a bug with the Octoprint plugin.

[fieldOfView]

A settings change window?

Anyway, after a fair amount of testing and debugging, I have come to the conclusion that this is caused by Qt, the GUI framework used by Cura. It was upgraded from 5.8 to 5.10. If I upgrade further to 5.11, the memory leak no longer happens.

I am looking for ways to work around this Qt bug. Also see Ultimaker/Cura#4626 (comment)

[Razwer]

settings change window is like when i would change profile and it would ask which settings to keep and which to discard (I.E. changing from PLA to PETG profiles i have set up). When i closed the window for that and change betweeen "prepare" and "monitor" it pops up very briefly.

[fieldOfView]

settings change window is like when i would change profile

That sounds like an unrelated issue then.

[Razwer]

settings change window is like when i would change profile

That sounds like an unrelated issue then.

since you already pinpointed the issue, for sure :)

Since your latest update, could it be that the image quality less? or am i just tripping? i'm too lazy to roll back and see the difference :)

[fieldOfView]

Since your latest update, could it be that the image quality less?

Good eye; the camera image was scaled using nearest neighbor. I have fixed that in the 3.5 branch. I am preparing a new release of the plugin. Your feedback is appreciated.

[Razwer]

Since your latest update, could it be that the image quality less?

Good eye; the camera image was scaled using nearest neighbor. I have fixed that in the 3.5 branch. I am preparing a new release of the plugin. Your feedback is appreciated.

your efforts are much more appreciated!

[fieldOfView]

A testing version of the new release 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.

[Razwer]

few hours down the line, things seems to look good:

[tenpaiyomi]

My memory usage has gone down, but I have noticed that performing any actions from the sidebar (move along an axis, pause/cancel a print, etc) causes Cura to just crash.

[fieldOfView]

Can you check Cura.log?

[tenpaiyomi]

Just updating, I've left the program overnight without any excessive memory usage (~230MB), however the crashing issue does persist.

[tenpaiyomi]

@fieldOfView

2018-10-27 09:48:38,498 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [65]: An uncaught error has occurred!
2018-10-27 09:48:38,501 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]: Traceback (most recent call last):
2018-10-27 09:48:38,503 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]:   File "X:\3.5\build\inst\lib\python3.5\site-packages\cura\PrinterOutput\PrintJobOutputModel.py", line 150, in setState
2018-10-27 09:48:38,504 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]:   File "X:\3.5\build\inst\lib\python3.5\site-packages\cura\PrinterOutput\GenericOutputController.py", line 73, in setJobState
2018-10-27 09:48:38,505 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]:   File "C:\Users\Eric\AppData\Roaming\cura\3.5\plugins\OctoPrintPlugin\OctoPrintPlugin\OctoPrintOutputDevice.py", line 283, in pausePrint
2018-10-27 09:48:38,506 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]:     self._sendJobCommand("pause")
2018-10-27 09:48:38,507 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]:   File "C:\Users\Eric\AppData\Roaming\cura\3.5\plugins\OctoPrintPlugin\OctoPrintPlugin\OctoPrintOutputDevice.py", line 426, in _sendJobCommand
2018-10-27 09:48:38,508 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]:     self._sendCommandToApi("job", command)
2018-10-27 09:48:38,510 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]:   File "C:\Users\Eric\AppData\Roaming\cura\3.5\plugins\OctoPrintPlugin\OctoPrintPlugin\OctoPrintOutputDevice.py", line 434, in _sendCommandToApi
2018-10-27 09:48:38,510 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]:     self.post(end_point, data, self._onRequestFinished)
2018-10-27 09:48:38,511 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]:   File "X:\3.5\build\inst\lib\python3.5\site-packages\cura\PrinterOutput\NetworkedPrinterOutputDevice.py", line 231, in post
2018-10-27 09:48:38,512 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]: TypeError: arguments did not match any overloaded call:
2018-10-27 09:48:38,513 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]:   post(self, QNetworkRequest, QIODevice): argument 2 has unexpected type 'str'
2018-10-27 09:48:38,514 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]:   post(self, QNetworkRequest, Union[QByteArray, bytes, bytearray]): argument 2 has unexpected type 'str'
2018-10-27 09:48:38,515 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [68]:   post(self, QNetworkRequest, QHttpMultiPart): argument 2 has unexpected type 'str'

From the backtrace, looks like the post method changed and the call on OctoPrintOutputDevice.py:434 needs to update accordingly.

[fieldOfView]

It looks like this is actually a bug in Cura: NetworkedPrinterOutputDevice.post takes data as a string, but should encode it before posting it to the QNetworkRequest), but I can work around it in OctoPrintOutputDevice.

The bug came to light by my adding stricter typing to the OctoPrint plugin, to prevent issues like this.

[fieldOfView]

See Ultimaker/Cura#4678
This should fix it for OctoPrintPlugin: 372107b
A new package can be downloaded here:
http://files.fieldofview.com/cura/OctoPrintPlugin-v5-2018-10-28T10_56_55Z.curapackage

[trouch]

Issue still is present with version 3.5.2 of the plugin (with Cura 3.5.1). After a fresh start, memory usage grow as soon we go into the Monitor panel, no matter we go into the printer settings.

Raised up to 60GB swap on my MacBook until it totally crashed 😱

A webcam is connected to my OctoPrint setup, but I have been able to disable the video preview in the monitor panel by unchecking the box, disabling the plugin, relaunching Cura, and enabling back the plugin.

At this point, memory usage still is growing despite there is no video preview in the monitor panel.

Best,

[fieldOfView]

@trouch could you test if this version of the plugin still exhibits the leak when you configure it not to display the camera image?
http://files.fieldofview.com/cura/OctoPrintPlugin-v5.0.0-2018-11-14T21_29_30Z.curapackage
Just drop the downloaded file into a running Cura window, and restart Cura.

Version 3.5.2 has a bug that even when not displaying the image, it is still being streamed and interpreted (oops).

[fieldOfView]

Closing due to inactivity. If you are still experiencing the memory leak and you are certain you are using the latest version of the plugin (3.5.3 at the time of writing this), please let me know.