New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(Possible) Memory Leak #33
Comments
You might want to check this again while not on the control tab...that memory consumption is because of the webcam I think. |
Yes, I did that. I happens while outside the webcam too, just starting octoprint and leaving it be, causes the memory consumption to grow and keep growing you terminate the process or crashing. I've so, 6 GiBs of extra memory... against 150-250 MiB (even with the webcam in the control tab) of normal consumption (with TabOrder disabled). |
This is Chrome's Task Manager. As the memory leak itself, I don't know what to say. I'm consistently getting it every time I enable the plugin. |
Yeah, I see it growing in the regular task manager. Not sure what has introduced this or if it's been there from the beginning. I'll try to figure this out. |
Ok, I think I've isolated the issue down to the latest release that incorporated an external library (bootstrap-tabdrop) for the ability to push items into the drop-down list, effectively "hiding" the tab from default view. This basically overwrites the bundled version of OctoPrint. Now, figuring out why it is happening will be a challenge, |
I think I got it. Went back the default bootstrap-tabdrop module included with OctoPrint and just patched it with the settings needed to push the hidden tabs into the drop-down. The caveat is we lose the label on the dropdown for the active tab, but I think killing a memory leak is more important. If you don't mind testing to confirm this does fix the issue that would be greatly appreciated. Use the URL below in Plugin Manager to install the updated version. https://github.com/jneilliii/OctoPrint-TabOrder/archive/0.5.7.zip |
Did you force a browser refresh to overwrite the local cache? |
Never mind. It's still a problem. I didn't leave it long enough before to know for sure. I'm curious if this issue has been there longer than my tabdrop modifications. Going to install an old version and see if it's the same. |
I'm testing version 0.5.4, and after few hours, it looks fine. |
I haven't shut down my browser tab running version 0.5.7 since last night and it is steady at ~200MB now, so I think whatever issue was there before is either specific to a certain condition/steps or not related to the plugin at all. |
I didn't have problems with 0.5.4 after several hours. |
I did just notice something @jrezin that is different to what you have versus what I have on my 0.5.7 version instance. You appear to be using "icon only" mode by not showing any labels, but on mine my labels are visible. At this point I'm just stabbing in the dark to isolate this issue and determine if it's specific to TabOrder or not. Edit: Doesn't appear to be icon only options. I changed my 0.5.7 instance to just icons and I'm still floating in the 200s. |
12 hours later and my instance is still hovering in the 200s... |
well, my setup current other enabled plugins:
|
@MFHFozzy, do you have any of these same plugin's installed? |
Common Plugins So Far and some assumptions since I don't use all these:
Once you see the higher memory usage does refreshing the page drop the memory back down? |
"OctoPrint 1.4.0 running on OctoPi 0.17.0". LayerDisplay - https://plugins.octoprint.org/plugins/layerdisplay/ 0.5.7 compared to 0.5.4, its 100MiB of extra memory usage from the start. |
Thanks @jrezin, the memory jump from 0.5.4 to 0.5.7 is more than likely due to the inclusion of the fontawesome icon picker. Let me pull together an update to 0.5.7 without that feature and let's see if the issue is still there or not and that will help in identifying if that is the true cause or not. Updates to come for additional testing. |
I reinstalled tab order 0.5.6 yesterday (from repo) on #1 of my octopies, but so far today no leaking. |
a few hours in with https://github.com/jneilliii/OctoPrint-TabOrder/archive/0.5.7_iconpicker_removed.zip and it looks like 0.5.4 levels of memory usage, does not appear to be leaking for now. |
So I think I've been able to get the full functionality from before without the memory leak. So far my testing of https://github.com/jneilliii/OctoPrint-TabOrder/archive/0.5.7_pureComputed.zip which converts the computed observables to pureComputed observables and removes the fa-lg class from being automatically added is doing well. If you do try it out, make sure to force a browser refresh. |
installed 0.5.7_pureComputed.zip last night, was using 0.5.7_iconpicker_removed.zip before. |
That's so strange. I left mine running overnight and although it did grow, it didn't get anywhere near that much. It did double though. @MFHFozzy is your |
Im trying to nail things down better, as nothing is making sense. In frustration, i opened octopi the other night in chrome, and i also did a print last night (small, 1 hour). This morning was at 822MB. (yay, at least i got a reproduction) Logging so far: 2020-04-05 1:50pm, removed tab order, bed visualizer from both 2020-04-07 4:13pm 2020-04-08 2:51pm 2020-04-08 2:53pm reisntalled tab order 0.5.6 on .92 from repo, restarted 2020-04-09 5:49pm 2020-04-09 5:49pm reisntalled bed visualizer 0.1.13 on .93 from repo, restarted 2020-04-10 1:57pm 2020-04-11 2:37am 2020-04-11 2:07pm 2020-04-11 2:15pm reinstalled tab order 0.5.6 on .93, bed visualizer 0.1.13 on .92 2020-04-11 3:19pm 2020-04-11 3:19pm 2020-04-13 1:10pm Chrome: 2020-04-13 to 2020-04-14 10:07am |
Great stats @MFHFozzy, but for the most part it looks like the leak is not present until that last day in chrome, which is what I've been testing with and haven't been able to get reliable reproduction of the issue. That did make me think though, what extensions do you guys have enabled/installed in chrome? I noticed during my memory heap snapshots in developer tools that there was memory being consumed by installed extensions, not just the page content. This may be something else that you guys could do to help diagnose. On the memory tab of developer tools take a heap snapshot, wait a couple of hours then press the little delete button followed by another snapshot, then switch the view mode to Statistics (or compare) and let's see where the consumption is happening. The files end up being pretty big, but if you can upload/share them somewhere it might also help. Like I said I haven't been able to reliably reproduce. There was another user on the community forum that was discussing memory leaks with AutomaticShutdown plugin. Also, have either of you tried with just TabOrder enabled to see if the issue persists? |
I have switched back to chrome, and will take some snapshots as described. |
I should mention that i has also saved a bunch of the measure reports from Waterfox as well. I dont know how to use them though :) I can post them if that will help. |
My printers are currently non-stop printing face shield parts for the covid-19 efforts in LA, so 1 change is that i cant let them just "sit" for a day anymore. I switched back to chrome @ 12:01am, took snapshots and recorded task manager tab memory values, then started another 3 hour print: 2020-04-17 12:01am Started 3 hour print ~3 hours later, after the print was done: So Chrome task manager sees a huge memory tab use by Octoprint, but the heap doesnt? Ive attached all the log files i have so far. Both heap files and the waterfox mem dumps 92-Heap-20200417T120509.zip |
Thanks @MFHFozzy, not sure about what's captured in those heap dumps but from what I've seen so far I don't think there's any personal information in them. I was seeing the same discrepancy between chrome task manager window and the heap snapshots, not sure what that means. I'm new to memory leak debugging. |
This issue has been automatically marked as stale because it has not had activity in 14 days. It will be closed if no further activity occurs in 7 days. |
Releasing version 0.5.8 that should resolve the memory leak issue and retain the icon picker by binding it only once to a popup editor form instead of every row. |
I'm not sure how to properly debug and provide proper data about this bug, but basically, enabling this plugin causes a huge memory leak and disabling it fixes it.
I've initially posted it, before narrowing the problem TabOrder, in this issue OctoPrint/OctoPrint#3405
The text was updated successfully, but these errors were encountered: