5

I maintain a gtk3 (though a mixture of gtk2hs and gi-gtk) application that serves as a standalone status bar for tiling window managers called taffybar.

Taffybar has a long standing bug where something happens that causes one of its windows (it can have multiple windows e.g. when displaying on multiple monitors) to stop updating completely (issue here). I have verified through various logging mechanisms that the code that is supposed to be updating the window IS in fact continuing to run. Also, if taffybar is displaying on multiple windows, windows will become affected one at a time -- that is, the hang only seems to affect the window on which it occurs, which rules out anything strange happening on the UI thread or something like that.

Unfortunately, I do not have a consistent way to reproduce the issue. What's worse is that I haven't even been able to come up with a way to detect the issue programmatically. With that said, it is relatively easy to get the issue to occur as it has gotten much worse recently with the new icon loading mechanisms that have been added (it seems to happen about once every 5 minutes in the latest version). This reminds me that another thing I should mention is that I am relatively certain that the issue has something to do with pixbufs and image display because I have never seen the issue occur when the workspace images module is not active.

I hate to ask a question without even being able to provide a consistent way to reproduce the issue, but I'm simply at a loss as to how to go about tackling/debugging this issue. It's hard for me to imagine how the behavior that I have described is even possible, actually. I'm hoping that something about the idiosyncratic nature of the issue might be enough for someone more knowledgable about gtk than I to make some guesses as to what the issue might be.

To make my questions as explicit as possible I'll phrase it as follows:

What could cause a gtk application window to hang (stop updating) without crashing the application or the UI thread, or affecting any of the other windows created by the application?

EDIT: One more interesting quirk of this bug is that even though the window stops updating, it still responds to mouse input.

EDIT2: Another thing worth noting is that occasionally, I have gotten this message:

gtkicontheme.c:3956:proxy_pixbuf_destroy: assertion failed: (icon_info->proxy_pixbuf != NULL)

I have also gotten the following message when I attempt to destroy the hung window in code:

Source ID 363524 was not found when attempting to remove it

I am loading icons from the icon theme sometimes

imalison
  • 335
  • 3
  • 8
  • 1
    How do you know it responds to mouse input? – Alexander Dmitriev Jun 19 '18 at 16:48
  • Because the application triggers external behaviors through EWMh (switches the window manager workspace in this case) – imalison Jun 19 '18 at 20:23
  • Are mouse event handler are part of the topmost GtkWidget? If yes, it's possible, that someone unrefs the 2nd widget. Thus nothing is displayed but handlers are still alive. [Debugging reference count problems](https://developer.gnome.org/gobject/stable/tools-refdb.html) – Alexander Dmitriev Jun 20 '18 at 06:03
  • Also double-check whether you interact with gtk _not_ from mainloop. I recently faced a bug with 'source I'd not found' and 'assertion x != null failed' and it was caused by described reason – Alexander Dmitriev Jun 25 '18 at 15:37
  • Yes, that was the first thing I checked as it has been a source of issues in the past. It's still a possibility, but it seems somewhat unlikely. – imalison Jun 25 '18 at 22:56

1 Answers1

0

I believe that the cause of this issue was simply that some UI updates were not being performed on the main UI thread. I can't be 100% certain of this because I was never able to reproduce. See this comment for more details:

https://github.com/taffybar/taffybar/issues/228#issuecomment-402591159

imalison
  • 335
  • 3
  • 8