dolfandringa
commented
2 years ago Ok, I did a little more digging.
Adding a return at the start of update_indicator and update_indicator_icon didn't change anything. So its probably not the appindicator code. I also manually executed the gsettings commands from the update script, and those didn't trigger it either. BUt I do see this code:
def set_wp_throttled(self, filename, refresh_level=RefreshLevel.ALL):
if not filename:
logger.warning(lambda: "set_wp_throttled: No wallpaper to set")
return
self.thumbs_manager.mark_active(file=filename, position=self.position)
def _do_set_wp():
self.do_set_wp(filename, refresh_level)
threading.Timer(0, _do_set_wp).start()which gets called from refresh_clock which itself gets called from clock_thread_method. Do I see correctly that the set_wp_throttled method starts a new thread on every cycle? And that thread is part of the GTK window? So could it be that the thread timer is therefore part of the window object, which python or GTKor gnome implements using a timerfd inode, which then shows up on the UI as part of gnome? And could it be that the timer is started, but the thread never stopped?
Version of Variety 0.8.9 on Fedora Workstation 36 with Gnome 42.4 with Xorg.
Describe the bug When run variety, for some reason two timerfd file handles are opened in gnome, every time variety runs through a cycle of code. I initially filed a bug report with gnome, because I didn't know what was causing it, and gnome is keeping the file handles open. But since I filed that report, I discovered it only happens while I am running variety. When I stop variety, the file handles stop increasing, and then when I start variety, more file handles get opened constantly. So it pretty clearly is related to the combination of variety and gnome. But where, I am not sure.
Specifically, what I noticed is that gnome-shell crashes because it has too many file handles open (above the single-process soft limit). When checking the open file handles on gnome with
lsof -p $(pidof gnome-shell), I see steadily increasing number ofa_inode [timerfd]file handles getting opened by gnome. The number never decreases and only increases. I used a small python script to monitor this (see the gnome bug report because I can't attach it here).As I said, as soon as I stop variety, the number stops increasing, and when I start variety, it starts going up again.
When starting variety with
-vfrom the terminal, it turns out, the number exactly increases by 2, every time the cycle of functions is executed in the output below. So it looks like when that code runs, 2 file handles are opened. As far as I understand it, the timerfd file handles are timers acting through file descriptors, using anonymous inodes. Not really sure about the details, but just a rough guess, could there by a python timer thread that gets started but never stopped on each cycle? It's still weird the file-handle is opened by gnome, not variety itself though. So it maybe is something that variety is triggering on gnome? But clearly 2 handles get opened by gnome on every cycle of variety.Attach Variety's log file
Desktop environment and version Gnome 42.4 with Xorg.
OS name and version Fedora Workstation 36
Attached files variety.log
Can't attach my config, so here it is pasted:
Thank you. -->