Bug 972257

We've hit it too. Looks like this is a recent update change/config problem that breaks the a11y. It should work with a clean new user or purged config. This was Rhel though, could you please try again with a new user on Fedora?

I see the same traceback. But when I try it in a LiveCD it does not crash. Probably connected to an existing config, yes.

Vitezslav, which config files should I try to purge to get dogtail working with my existing user profile? Thanks.

I see the same error when running accerciser:

** (accerciser:3550): WARNING **: AT-SPI: Error in GetItems, sender=org.freedesktop.DBus, error=The name :1.0 was not provided by any .service files
Traceback (most recent call last):
  File "/usr/lib/python3.3/site-packages/accerciser/accessible_treeview.py", line 327, in _popOnIdle
    row = self._buildRow(child)
  File "/usr/lib/python3.3/site-packages/accerciser/accessible_treeview.py", line 454, in _buildRow
    role = accessible.getLocalizedRoleName()
  File "/usr/lib64/python3.3/site-packages/gi/types.py", line 113, in function
    return info.invoke(*args, **kwargs)
gi._glib.GError: The name :1.0 was not provided by any .service files

Traceback (most recent call last):
  File "/usr/lib/python3.3/site-packages/pyatspi/registry.py", line 193, in eventWrapper
    return callback(event)
  File "/usr/lib/python3.3/site-packages/accerciser/accessible_treeview.py", line 701, in _accEventChildChanged
    self._addChild(iter, event.source)
  File "/usr/lib/python3.3/site-packages/accerciser/accessible_treeview.py", line 750, in _addChild
    row = self.model._buildRow(new_child)
  File "/usr/lib/python3.3/site-packages/accerciser/accessible_treeview.py", line 454, in _buildRow
    role = accessible.getLocalizedRoleName()
  File "/usr/lib64/python3.3/site-packages/gi/types.py", line 113, in function
    return info.invoke(*args, **kwargs)
gi._glib.GError: The name :1.0 was not provided by any .service files


at-spi bug?

Probably late, though for us it was anything to do with dconf. Didn't manage to figure out what keys or what in specific it was. Fortunately this doesn't seem to occur anymore with updates. Was 3.6->3.8 business.

While running 'make check' on gnome-weather, the written dogtail tests are failing with same error. 

In this case also, error is erratic. Sometimes when I boot my pc after a long time, it just resolves and UI tests works fine. The next time I boot, there is no gurrantee that the tests will work, they usually fail with this concerned error.

I also suspect the config files to be the cause but do not know how I can clean the config files for modules like dogtail, at-spi2-atk, at-spi2-core. I am running the 'make test' inside jhbuild shell. I have also jhbuilt dogtail, at-spi2-atk, at-spi2-core modules.

Well, this whole issue is somewhat random as to what brings the bus to behave this way. There's no apparent reason why this happens to an user. Once the bus breaks this way for a user it's reproducible for some time and them may go back to normal. 

Clearing configs or working with a new user is just a workaround that doesn't tell us much about the cause. This likely lies with the at-spi/pyatspi in relation to how the session bus gets run. Not an dogtail issue, if you work with plain pyatspi, you hit this as well. Switching to at-spi, please ping the at-spi guys if you need this escalated. They may also know better what specific configs to try clear out, dogtail pretty much doesn't store any user-wide ones.

Worth mentioning that Orca works without any issues.

I've seen this before.

When I experienced the problem, what was taking place was some app somewhere was showing up as dead -- at least insofar as the at-spi2 registry is concerned. Accerciser was getting tripped up and failing to build its tree of accessible apps and objects.

Dead apps are bad and this problem should of course be fixed at the source. What I hoped to be able to do is call get_process_id () on the accessible Application. But that not only failed to provide the answer, it crashed the app in which you did the call. Mike fixed the crashed-your-app issue [1], but that's not going to magically give you the process id of the dead app. So I don't know how to hunt down the actual/original bug source. :( But....

What Orca does, and what a quick hack I did for my local copy of Accerciser does, is check if app.name == ''. You can do this safely even without Mike's fix for get_process_id (). If that returns True, you have a dead app hanging around on the registry. You do not want to touch that app. It is not your app. It has no useful information. Dance around it gracefully. If you add this sanity check to dogtail's and accerciser's tree-building functionality, things will start working as you expect and you can resume getting things done.

Perhaps at-spi2 itself should do some periodic checks to see if dead apps are hanging around and clean them up so such sanity checks are not needed. But having maintained Orca for a number of years, trust me when I tell you that there will always be some badly-behaved app somewhere and a simple sanity check is worth adding to your testing tools. ;)

[1] https://git.gnome.org/browse/at-spi2-core/commit/?id=2554a07c0bbee7defef5b2fca3a420d6cf42a770

Thanks for that insight Joanie. Shall we re-assign it back to dogtail now?

Hi Joanmarie, indeed looks like a solid pointer to the cause of this particular issue. I am testing a hackfix for this to move along such damaged apps when doing a query in dogtail. Still keeps being an at-spi problem, but could help bypass this for dogtail.

Rishi, this being just a dogtail hackfix of the original a11y issue, I'd keep the bug itself with at-spi if someone ever manages to get to the very root of this.

On the other hand, we don't really know what component(crashing app?) is to blame here and at-spi might not be the proper one either. So let's take this bug by the original dogtail-related meaning and file a new one if issue reappears elsewhere.

There's currently talk about putting a sanity check in at-spi2 itself (i.e. upstream gnome). When there's a conclusion, I'll update this bug for the sake of documentation.

Conclusions from the GNOME Accessibility Team meeting: We will add a check to at-spi2 for the 3.12.1 release: https://bugzilla.gnome.org/show_bug.cgi?id=726781

That won't solve the problem for earlier clients, however, so the dogtail hackfix is still recommended.

Indeed we'll put the check in dogtail too, so that the issue gets tackled with older versions of at-spi2 as well. Thanks again for the insight and info on this.

Finally got myself a session broken nicely in this fashion and fixed (workarounded) this upstream as 4e5e19a17b7df43 (framework) and 5c1e1f62935188 (sniff). Landing in 0.8.3

dogtail-0.9.0-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dogtail-0.9.0-1.fc20

dogtail-0.9.0-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/dogtail-0.9.0-1.fc19

Package dogtail-0.9.0-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dogtail-0.9.0-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-5297/dogtail-0.9.0-1.fc19
then log in and leave karma (feedback).

dogtail-0.9.0-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Hello,
I have run into this issue, but in an Xvfb instance. This means that the message was not about ":1.0" but ":1.4" so the workaround failed, since the patch basically checks on the exact string:

if 'name :1.0 was not provided' in e.message:

I manually fixed it on my instance, so it can work on many display. But just so this is out there, I am letting you guys know. This is what I did, but feel free to improve: I replaced the above tests with this:

if re.match("name :[0-9]+\.[0-9]+ was not provided", e.message):

Hope this helps,
Yannick

Hi Yannick, thanks for the multi-screen observation! I am patching that in upstream dogtail and it will land in 0.9.1.