GNOME Bugzilla – Bug 728319
Hangs when browsing using artist view
Last modified: 2014-10-18 22:19:18 UTC
I've just updated to Rhythmbox 3.0.2 from 3.0.1 (Fedora 20 64-bit), and I'm suffering from new hangs of about 15 seconds while browsing using the artist view. They happen in (at least) two occasions: 1) When I type one or more characters to find an artist. 2) When I select "All XXX artists" (after having selected another entry); selecting any actual artist does not create a hang, but there's a delay which seems to be related to the number of songs of this artist I have. My library is relatively large, with 200 artists and 7000 songs. Below is a stacktrace I obtained while RB was hanging after I typed one character in the artists view. The first interrupt was done about 1 second after I hit the key, and the second one a handful of seconds later. Why is D-Bus involved at all?! Program received signal SIGINT, Interrupt. _int_realloc (av=av@entry=0x336bfb8760 <main_arena>, oldp=oldp@entry=0x7239160, oldsize=oldsize@entry=32, nb=nb@entry=48) at malloc.c:4225 4225 newmem = _int_malloc(av, nb - MALLOC_ALIGN_MASK); (gdb) ba
+ Trace 233475
(In reply to comment #0) > Why is D-Bus involved at all?! a11y:
+ Trace 233477
rhythmbox throws everything in a huge tree view, which means atk has to emit lots of notifications, which doesn't work especially well. I've added a few hacks to try to reduce the impact of all of this, but it doesn't help all that much.
Ah. But why didn't this happen in previous releases? Maybe something else has changed on my system? I guess it's hard to do with GtkTreeView, but it doesn't make any sense to spam ATK with so much information, there's no chance the user will be able to listen or read all of this data. Would it be possible to only send the rows around the current selection?
I've seen a few different reports of this (bug 728369 for one) that say it started after upgrading from gnome 3.10 to 3.12, so I'm guessing some amount of a11y got enabled by default in that cycle. I don't think the application has any control over how much of the tree view gets exposed through atk.
Thanks. Indeed, downgrading Rhythmbox to 3.0 didn't make any difference, so the change must have happened elsewhere. But I'm not on GNOME 3.12, I'm still with 3.10 on Fedora 20, so I'm not sure what's changed. Killing AT-SPI processes makes the problem disappear. But the goal of enabling accessibility by default is precisely that people test and report bugs, so let's move this to AT-SPI. I'm using at-spi2 2.10.2.
Created attachment 274855 [details] [review] Proposed patch. Is anyone able to test this patch to see whether it improves things? It looks as though gtk's accessibility code is sending a flood of children-changed events. I'm hoping that it will help to check the state of the objects and not propagate these children-changed events if no one is explicitly listening for them--the only reason for propagating them is to keep the AT's cache updated, but the cache isn't used for transient accessibles anyhow.
I have the same issue in rythmbox (934 artists/14278 songs), on archlinux x86_64 up to date, since the update to gnome 3.12 (downgrading rhythmbox didn't change). The problem also seems to disapear when I stop at-spi2-registryd but downgrading to at-spi2-core-2.10.2-1-x86_64 and/or at-spi2-atk-2.10.2-1-x86_64 (and reboot) doesn't correct it... I never tried to patch so I don't know how to, but I'll be glad to try if someone can tell me. Would the use of archlinux be a problem ?
Thanks, Mike! Unfortunately I can't build GTK from sources to test the patch ath the moment. If you have some more time, there's a script here to generate a fake Rhythmbox database to reproduce the problem: https://bugzilla.gnome.org/show_bug.cgi?id=699832#c12
*** Bug 729539 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Created an attachment (id=274855) [details] [review] > Proposed patch. > > Is anyone able to test this patch to see whether it improves things? It looks > as though gtk's accessibility code is sending a flood of children-changed > events. Although the bug is already closed, just wanted to share why this flood is happening. Here a converstation on #gtk+ in relation to bug 730118: <API> Company, this was a problem with gtk 2.xxx <API> and afair, you were able to solve it <API> or at least mitigate it on gtk 3.y (y < 12) <API> am I wrong? <Company> until < 3.12 the treeview just didn't emit object-added I think <Company> and now it's technically correct and that blows everything up <API> well, as you mentioned, there is the MANAGES_DESCENDANTS flag <API> in theory under that state you dont enumerate all the children <API> <Company> and now it's technically correct and that blows everything u <API> hmm <API> so something changed? <Company> yes <API> Company, due any specific bug? <Company> 3.10 randomly crashes due to broken refcounting <API> ah yes, I remember that conversation <API> vaguely in any case So in summary, since 3.12 gtktreeview is again emitting children-changed events.
Thanks for sharing this, but I have to admit I don't really understand. I'm experiencing the bug with 3.10, I've never tried 3.12 (though it seems the bug has appeared with recent updates, so maybe some commits were backported to 3.10). (And FWIW this bug isn't closed...)
(In reply to comment #10) > Thanks for sharing this, but I have to admit I don't really understand. I'm > experiencing the bug with 3.10, I've never tried 3.12 Ok. > (though it seems the bug > has appeared with recent updates, so maybe some commits were backported to > 3.10). It's a possibility. The change was related to wrong refcount (so leaks), so it is possible that was backported, we would need to check. > (And FWIW this bug isn't closed...) Yes sorry, my bad, as I saw a commit on at-spi2-core master mentioning this bug, I assumed that the bug was closed.
I'm sorry for not replying sooner. I committed the change for at-spi2-atk 2.13.1, since I *think* that it is an improvement. Thanks for the script; I'll take a look at it. It should be helpful for testing.
Looks like it's gone with GTK 3.10.9 in Fedora 20. Should I close the bug? Thanks for the fix!
Looks like the bug has come back. I've updated a bunch of packages, including gnome-shell (3.10.4-6), but not GTK nor Rhythmbox... Any ideas?
I'm still experimenting this issue under GNOME 3.13.92. I was very excited when I saw this commit: a11y: set again NO_AT_BRIDGE=1 before calling meta_init() https://git.gnome.org/browse/gnome-shell/commit/?id=9896135c97ae513614310d46d10c7d175117f2a9 So I built gnome-shell from master and restarted it. But the issue is still there. The only way Rhythmbox is usable is to kill the at-spi-bus-launcher and at-spi2-registryd before starting it. But if gnome-shell restarts, I have to re-kill them again... I've also noticed that caribou is running by default in GNOME 3.13.x even if I don't have the on-screen keyboard enabled or any other accessibility option... I hope this bug can be closed soon, since I've been living with it for more than six months now (I'm already used to kill the at-spi processes after each boot... :P )
(In reply to comment #15) > I'm still experimenting this issue under GNOME 3.13.92. That's unfourtunate, I thought that this would be solved with bug 730118. > I was very excited when I saw this commit: > a11y: set again NO_AT_BRIDGE=1 before calling meta_init() > https://git.gnome.org/browse/gnome-shell/commit/?id=9896135c97ae513614310d46d10c7d175117f2a9 FWIW, this change was not related to that. > So I built gnome-shell from master and restarted it. But the issue is still > there. > The only way Rhythmbox is usable is to kill the at-spi-bus-launcher and > at-spi2-registryd before starting it. > But if gnome-shell restarts, I have to re-kill them again... > I've also noticed that caribou is running by default in GNOME 3.13.x even if I > don't have the on-screen keyboard enabled or any other accessibility option... Caribou is used for the on-screen keyboard, but by default, it is not using at-spi2 at all. So in theory, this shouldn't be the accessible tool being initialized. > I hope this bug can be closed soon, since I've been living with it for more > than six months now (I'm already used to kill the at-spi processes after each > boot... :P ) Bug 730118 comment 7 includes a way to monitor dbus messages. Could you use it, in order to confirm that the problem is the same?
(In reply to comment #16) > (In reply to comment #15) > > I'm still experimenting this issue under GNOME 3.13.92. > > That's unfourtunate, I thought that this would be solved with bug 730118. > > > I was very excited when I saw this commit: > > a11y: set again NO_AT_BRIDGE=1 before calling meta_init() > > https://git.gnome.org/browse/gnome-shell/commit/?id=9896135c97ae513614310d46d10c7d175117f2a9 > > FWIW, this change was not related to that. > > > So I built gnome-shell from master and restarted it. But the issue is still > > there. > > The only way Rhythmbox is usable is to kill the at-spi-bus-launcher and > > at-spi2-registryd before starting it. > > But if gnome-shell restarts, I have to re-kill them again... > > I've also noticed that caribou is running by default in GNOME 3.13.x even if I > > don't have the on-screen keyboard enabled or any other accessibility option... > > Caribou is used for the on-screen keyboard, but by default, it is not using > at-spi2 at all. So in theory, this shouldn't be the accessible tool being > initialized. > > > I hope this bug can be closed soon, since I've been living with it for more > > than six months now (I'm already used to kill the at-spi processes after each > > boot... :P ) > > Bug 730118 comment 7 includes a way to monitor dbus messages. Could you use it, > in order to confirm that the problem is the same? I had a look at the pointed debug log and at the one I generated and they look really similar. Mine is quite bigger, since I have 1019 artists and 24404 songs... So it takes a while to load... I will add the attachment
Since the log is too big, I'll give you a link: https://dl.dropboxusercontent.com/u/488112/dbus-monitor.log.tar.xz
(In reply to comment #18) > Since the log is too big, I'll give you a link: > https://dl.dropboxusercontent.com/u/488112/dbus-monitor.log.tar.xz Thanks for confirming. I will take a look to this bug, and hopefully it would be solved 3.14.1
I haven't time to do a trace to check I understand the nature of the bug properly yet today. With that said, a quick look at the CPU rhythmbox uses as the application starts up with "top" shows it uses ~24% (which would likely be 100% of one of my CPUs), I believe this patch I made in January to deal with accessibility.conf's inconsistent and potentially insecure configuration may well fix this problem. In any case, it seems to stop the application start-up from using ~24% of my 4 CPUs Try it. https://bug722738.bugzilla-attachments.gnome.org/attachment.cgi?id=266935
Comment on attachment 274855 [details] [review] Proposed patch. This was already committed on the previously release. Although it somewhat improved the situation, it was not enough.
Created attachment 286996 [details] [review] Aggressively filtering AddChildren with STATE_MANAGES_DESCENDANTS This patch is even more aggressive filtering events that the previous one. It checks for the state MANAGES_DESCENDANT even before, at the AtkObject::children-changed callback, discarding it if is present. For me it improves the situation, and after a quick check with Orca, Orca is able to expose the content of the little example included on bug 730118 comment 2. Anyway, some more testing would be needed. Posting here to get feedback from the bug reporter. It would be awesome if you are able to test this patch.
(In reply to comment #22) > Created an attachment (id=286996) [details] [review] > Aggressively filtering AddChildren with STATE_MANAGES_DESCENDANTS > > This patch is even more aggressive filtering events that the previous one. It > checks for the state MANAGES_DESCENDANT even before, at the > AtkObject::children-changed callback, discarding it if is present. > > For me it improves the situation, and after a quick check with Orca, Orca is > able to expose the content of the little example included on bug 730118 comment > 2. > > Anyway, some more testing would be needed. Posting here to get feedback from > the bug reporter. It would be awesome if you are able to test this patch. Should I apply the patch to which piece of software? at-spi2-atk?
(In reply to comment #23) > (In reply to comment #22) > > Created an attachment (id=286996) [details] [review] [details] [review] > > Aggressively filtering AddChildren with STATE_MANAGES_DESCENDANTS > > > > This patch is even more aggressive filtering events that the previous one. It > > checks for the state MANAGES_DESCENDANT even before, at the > > AtkObject::children-changed callback, discarding it if is present. > > > > For me it improves the situation, and after a quick check with Orca, Orca is > > able to expose the content of the little example included on bug 730118 comment > > 2. > > > > Anyway, some more testing would be needed. Posting here to get feedback from > > the bug reporter. It would be awesome if you are able to test this patch. > > Should I apply the patch to which piece of software? at-spi2-atk? Yes, the patch is for at-spi2-atk.
(In reply to comment #24) > (In reply to comment #23) > > (In reply to comment #22) > > > Created an attachment (id=286996) [details] [review] [details] [review] [details] [review] > > > Aggressively filtering AddChildren with STATE_MANAGES_DESCENDANTS > > > > > > This patch is even more aggressive filtering events that the previous one. It > > > checks for the state MANAGES_DESCENDANT even before, at the > > > AtkObject::children-changed callback, discarding it if is present. > > > > > > For me it improves the situation, and after a quick check with Orca, Orca is > > > able to expose the content of the little example included on bug 730118 comment > > > 2. > > > > > > Anyway, some more testing would be needed. Posting here to get feedback from > > > the bug reporter. It would be awesome if you are able to test this patch. > > > > Should I apply the patch to which piece of software? at-spi2-atk? > > Yes, the patch is for at-spi2-atk. I just patched at-spi2-atk and rebuilt it and the problems seems to have gone away! Thank you :D
(In reply to comment #25) > I just patched at-spi2-atk and rebuilt it and the problems seems to have gone > away! Thank you :D I did the same (to verify nothing would break for Orca users), and a pesky event flood went away -- without breaking anything for Orca users. <grumble>I hate accessible-event floods.</grumble> So Thank you++. :)
As we would like to have this included on 3.14.1. I'm setting the target to 3.14. Just to be clear that Im talking about 3.14.1 and not the already released 3.14.0, Im adding 3.14.1 to the whiteboard.
Comment on attachment 286996 [details] [review] Aggressively filtering AddChildren with STATE_MANAGES_DESCENDANTS Looks fine to me. Thanks for the patch and for testing.
Committed (c8cda37e28307ad195996ad54b9ee1680cca3ec3). Closing bug. Thanks everybody.
*** Bug 738723 has been marked as a duplicate of this bug. ***