Re: Leaky at-spi-registryd update



Hi Nolan:

If one of the suspects is FF, I wonder if we might be able to focus on it a little more. For example, I wonder if it might be possible that it is some of the web sites you typically visit and/or maybe some usage patterns (e.g., frequently opening/closing multiple FF tabs or windows).

While still respecting your privacy, are you able to share some of the typical pages you visit in a day?

Will

Nolan Darilek wrote:
Part update, part ping. A couple weeks ago I filed this:

http://bugzilla.gnome.org/show_bug.cgi?id=568803

Just wondering if anyone has any thoughts on it? It's still here, it still has me rebooting every twelve hours, it currently has my system looking a bit like a 1970s line terminal with it lagging so badly that it takes 10-30 seconds for the keys I type to speak. :) Currently at-spi-registryd has 20.5% of my memory. By way of comparison, all of Firefox has 21 and Thunderbird has 6.5. Is it not strange that a web browser known as a memory hog is using only slightly more than a process that's supposed to run accessibility? If this is normal, do let me know, but it still strikes me as strange that it happily uses less than 1% for hours then suddenly starts spiking. Shortly after I have to restart my X session or reboot, losing my workspace setup.

I've run at-spi-registryd under valgrind. Its leak tool seems to indicate that at-spi-registryd itself isn't leaking, but it does show it using hundreds of megs of memory on exit. It was suggested to me that I figure out how to get valgrind to list all mallocs and frees, but looking through the manual hasn't shown me how yet, and I'm honestly not that great at this stuff, which is why I asked for debugging advice. :)

I've tried swapping out apps--Evolution for Thunderbird, Firefox 3.0/3.1/3.2. Yesterday I went without Pidgin for a few hours, and thought that was helping, but soon my at-spi-registryd started growing again. The only thing I've not done without is Firefox, and since the problem doesn't surface unless I've been actively using the box, cutting out FF would eliminate much of my need for active use. I'm kind of at a loss as to what to try next, but I have three less than ideal solutions.

1. Upgrade to Jaunty and hope that fixes the issues. Since I honestly don't remember when these began, it very well could have been with Intrepid. Is anyone running Jaunty regularly? How's it working out? I may ask on the ubuntu-accessibility list since that question is probably best posed there.

2. Switch to the dbus at-spi. I realize it isn't ready for prime time, but if it can run for longer than 12 hours sans the need to kill my X session, I'd consider a loss of some functionality a win. How is this work coming? I recently checked the wiki page and it's still showing last November's update, though I'm following git and notice more recent changes.

3. Jumping ship away from Linux entirely.

I know that I'm the only one experiencing this. I know it's strange, and I know that the GNOME accessibility community isn't my personal tech support staff. I just wish I had *some* clue as to why at-spi-registryd is dragging this box to a grinding hault every 12-24 hours. I wonder if the problem isn't at-spi-registryd at all. The valgrind log shows 92 loss records but only seems to display info on a few. I suppose the problem could be in orbit as well, making it even more likely that a switch to at-spi2 might solve this for me. I just don't have a clue. Does the registryd have any way to, I don't know, connect and see what has registered with it? Maybe some app or toolkit has registered 8 million of whatever the registryd registers, and this is eating all my memory? See how little I know about this stuff? :)

Thanks a bunch for any help. Looking forward to having a few days of uptime again.
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]