Open netikras opened 3 months ago
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
use Devel::Leak::Object qw{ GLOBAL_bless };
in the modules section (around line numbers 30-40 in /usr/bin/shutter
). Then, when you launch Shutter from CLI and after a few weeks exit it, there will be output about leaks at the end of the output. After a very short run I got
Tracked objects by class:
Class::Struct::Tie_ISA 1
Encode::utf8 3
Errno 1
Gtk3::ImageView::Tool::Dragger 4
Locale::gettext 1
Method::Generate::Accessor 3
Method::Generate::Constructor 3
Moo::HandleMoose::AuthorityHack 1
Moo::HandleMoose::_TypeMap 1
Net::DBus::Annotation 4
Number::Bytes::Human 1
POSIX::SigRt 1
Readonly::Scalar 5
Shutter::App::Autostart 1
Shutter::App::Common 1
Shutter::App::HelperFunctions 3
Shutter::App::Menu 1
Shutter::App::ShutterNotification 1
Shutter::App::SimpleDialogs 5
Shutter::App::Toolbar 1
Shutter::Pixbuf::Load 3
Shutter::Pixbuf::Save 1
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 ps
was captured moments after starting up the shutter. With this debug module enabled it took quite a while to start up. That's the reason behind the high CPU% in ps
's output (and we know that ps
is cumulative, so it's quite inert)
Finally...
Process RSS was 1GB
Tracked objects by class:
Class::Struct::Tie_ISA 1
Encode::Internal 1
Encode::utf8 3
Errno 1
Gtk3::ImageView::Tool::Dragger 794
Gtk3::ImageView::Tool::Selector 62
Locale::gettext 1
Net::DBus::Annotation 4
Number::Bytes::Human 1
POSIX::SigRt 1
Readonly::Scalar 5
Shutter::App::Autostart 1
Shutter::App::Common 1
Shutter::App::Directories 1
Shutter::App::HelperFunctions 3
Shutter::App::Menu 1
Shutter::App::ShutterNotification 1
Shutter::App::SimpleDialogs 5
Shutter::App::Toolbar 1
Shutter::Draw::DrawingTool 1
Shutter::Pixbuf::Load 3
Shutter::Pixbuf::Save 1
Shutter::Screenshot::History 52
Shutter::Screenshot::SelectorAdvanced 51
Shutter::Screenshot::Workspace 1
@DarthGandalf Looks like Gtk3::ImageView::Tool::Dragger
is only used inside the editor (DrawingTool.pm
). There is a DESTROY
sub but it is commented out and not used. Maybe it should be restored and used on closing the editor?
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 bin/shutter
. Thanks!
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.
$ ps aux | head -1; ps aux | egrep '[.]/shutter'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
user1 1532888 1.0 0.5 1788660 375296 pts/152 Sl+ 08:43 1:19 /usr/bin/perl ./shutter
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