-
-
Notifications
You must be signed in to change notification settings - Fork 35
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 #661
Comments
Thanks for your bug report! I will try to catch the leak(s) with Devel::Leak::Object, let's see, how this works out! You could also join the testing, if you have the resources. You'd need to install Devel::Leak::Object to do so though. Then just add
in the modules section (around line numbers 30-40 in
But I assume that after a few weeks there will be entries with a high number of objects, so we can find the leak(s). |
Alright, I'm joining the witch hunt! $ ps aux | grep -E "^USER|shutter"
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
user1 38088 0.0 0.0 0 0 ? Z 2022 72:49 [shutter] <defunct>
user1 550290 0.0 0.0 0 0 ? Z 2023 42:11 [shutter] <defunct>
user1 1326863 0.0 0.0 0 0 ? Z 2022 82:33 [shutter] <defunct>
user1 3015878 0.0 0.0 0 0 ? Z 2023 46:06 [shutter] <defunct>
user1 3108262 54.9 0.3 2094728 237520 pts/10 Sl+ 08:26 1:16 /usr/bin/perl /usr/bin/shutter
user1 3108263 0.0 0.0 10684 580 pts/10 S+ 08:26 0:00 tee /tmp/shutter.log
user1 3109610 0.0 0.0 11580 2696 pts/34 S+ 08:29 0:00 grep --color=auto -E ^USER|shutter
user1 3590463 0.0 0.0 0 0 ? Z 2023 75:24 [shutter] <defunct> (I wonder why so many zombies... Prolly unrelated to the memleak anyways :) ) Current RSS usage -- ~227M with 673 screenshots loaded |
I'm also surprised by the 54.5% CPU usage... Is it just a short peak, or is the CPU usage high for longer periods of time? |
@Photon89 |
Finally... Process RSS was 1GB
|
@DarthGandalf Looks like |
I don't understand why Dragger is created there at all, it doesn't seem to be used |
@netikras I have created a branch where the problematic object isn't being initialized: https://github.com/shutter-project/shutter/tree/debug-661 Could you test it and see if it fixes the issue for you? Just check out the branch or download it as an archive, then run edit: You might need to install this new dependency if you have used v0.99.2 so far: https://metacpan.org/pod/Moo |
Starting testing.
|
Are there any news on the memory consumption of the experimental branch? |
@Photon89 Hi! I started it in a separate terminal and left it running. Only now, when you pinged me, I went to check and found that it was no longer running. Exit code is 0, but I can't recall any reason I would manually exit the app. In the terminal console I see lots of records at the end of execution (see below), IDK if they suggest an abrupt termination due to an error or whether they are normal should I restart testing?
(in the output mind the line numbers: 3200 and 3199) |
I may have been running it off master... 😅 Restarting off the new branch now |
Damn, yeah, looks like master... Sorry for your time spent for nothing! |
Still monitoring. Current RSS size: ~700M
|
I think, that's enough, could you please post another leak output? |
Sure!
And this time I think I was on the correct branch :)
|
I have no explanation for this, there are only two occasions where Gtk3::ImageView::Tool::Dragger has been initialized, one of them is already commented out in master, the other one is additionally commented out in the debug branch... You can check it yourself with There should be two hits, both commented out:
|
IDK what to say either :) Could it be second-line dependencies? Full disclosure. I'm launching shutter from your binary. However, I'm working with 18 active workspaces, and lugging the shutter window across them is a tedious chore. Clicking on the shutter icon in a status bar is an options, but that's also not too convenient. Instead, I do [winlogo]→"shutt"→[enter] (as if I'm launching shutter anew) and the shutter window pops up. If there's no woodoo magic going on and your dependencies don't depend on Dragger themselves, I can't explain why there's Dragger in the report either. |
RSS seems to be growing when I'm editing the screenshot. Could it be related? Does Dragger come from the editing feature? RSS doesn't seem to go down after I close the editor |
Well, initially the object has been initialized in DrawingTool.pm that is responsible for the editor. But I commented it out and don't understand why it is still there... |
I see this even if I start your executable, wait for it to load all the screenshots and close it off. No win_logo, no editing, no clicking anywhere on the shutter window. |
To exclude the possibility of mixing several Shutter versions, I propose to edit the installed files directly and then run Shutter from /usr/bin. Here are the necessary changes: master...debug-661
|
There is no DrawingTool.pm in my installation? There is one under
Is this the one? |
I guess so, looks like the packager for your distro decided to put all perl modules into /usr/share/perl5. |
nope, still the same. Well OK, almost the same :D For some reason it now loads only ~half of the screenshots I have in my library. The number of Dragger instances' corresponds to the number of loaded screenshots.
|
But the RSS usage at start is still low, even though there are several hundred instances of Dragger? Possibly we should concentrate on the other objects which have far less instances but might accumulate over time and consume more and more RSS. For example, there are 22 instances of Still, it's an interesting question, how Dragger gets into play. Probably somewhere in the definition of Line 4342 in bce8db8
|
I pushed a commit which might reduce the memory leak, could you please test? |
now it won't start
|
Sorry, I copy&pasted a line one line off... Could you test again? Sorry! |
it's all fine, after all, you're doing it for me (us) :))) After initial startup this is the summary
And this is the
Should I have it running for a few days now, or is there any other testing method you'd recommend? |
If you could observe an increase in RSS by using the editor, maybe you could test whether this is still the case. It should free the memory after closing the editor now. Also, after taking a screenshot, such that Shutter::Screenshot::SelectorAdvanced won't accumulate. |
Okay, so i dived into this issue a little bit deeper. Unfortunately, I have never dealt with memory management before, so I am kind of groping in the dark here. I am now able to watch the memory consumption at any line of code using Regarding the many Gtk3::ImageView::Tool::Dragger instances, they are being spawned from inside |
IDK, I don't normally close tabs in shutter. However, after a week's of use RSS grows substantially, and after shutter restart RSS drops significantly. Unless... when editing a screenshot, a new version of the screenshot means closing the original tab and opening a new (redacted screenshot) tab? That would explain the connection between RSS rise and you looking into the tabs-closing-memory-unreleased issue. |
No, sorry for the confusion. Closing tabs was just an example. Another example is taking screenshots. The editor, however seems to be fine to me, at least in the debug branch. |
Brief summary of issue
Over time Shutter memory usage grows inadequately high
Steps to reproduce the issue
It's not the first time I see Shutter among the top RAM consumers. Restarting it drops memory usage significantly. E.g. just now I was struggling with free memory and I found that Shutter was using ~2.6GB of RAM. After restarting it - it indexed the same the same 207 screenshots I have (70MB) and now the process only weights 169.348M. Over time I expect this number to slowly creep into gigs.
I wish I could provide anything more useful, anything to work with, but I don't know what info you may need nor how to capture it. The RAM leak will become apparent over time, so if I had instructions - perhaps I could capture some diag info for you.
Extra information, such as Shutter version, display server in use (Xorg or Wayland), operating system and ideas for how to solve:
0.99.2 Rev.1593
The text was updated successfully, but these errors were encountered: