GNOME Bugzilla – Bug 776292
Memory leak in error handling of utimes on podcast-timestamp
Last modified: 2016-12-19 22:09:03 UTC
I wanted to use my Podcast and Music files from two different accounts (one for work, one for personal) so I made symlinks for ~/Music and for ~/.local/share/rhythmbox. I used setfacl -R -m newaccount:rwX ~/Music ~/.local/share/rhythmbox to add permissions for the other user account. However, Rhythmbox fairly quickly consumes 16 GB and crashes via OOM. strace shows that the only thing it does during this time is repeatedly try to stat() and utimes() the .local/share/rhythmbox/podcast-timestamp file. utimes() fails with "Operation not permitted" because Rhythmbox is not running as the file owner. The error handling is very broken here, because it never handles it or reports an error or exits the application or even tries to remove the file and recreate it. It simply runs in a loop until it dies.
(In reply to Jonathan Briggs from comment #0) > I wanted to use my Podcast and Music files from two different accounts (one > for work, one for personal) so I made symlinks for ~/Music and for > ~/.local/share/rhythmbox. I used setfacl -R -m newaccount:rwX ~/Music > ~/.local/share/rhythmbox to add permissions for the other user account. this is a very bad idea. > However, Rhythmbox fairly quickly consumes 16 GB and crashes via OOM. strace > shows that the only thing it does during this time is repeatedly try to > stat() and utimes() the .local/share/rhythmbox/podcast-timestamp file. > utimes() fails with "Operation not permitted" because Rhythmbox is not > running as the file owner. > > The error handling is very broken here, because it never handles it or > reports an error or exits the application or even tries to remove the file > and recreate it. It simply runs in a loop until it dies. commit c9b8f52 fixes this about as well as it's ever going to get fixed.