Bug#859262: Re: freezes Orca screen reader

Niels Thykier niels at thykier.net
Wed Apr 19 20:19:00 UTC 2017

Paul Gevers:
> Hi
> On 19-04-17 01:13, Niels Thykier wrote:
>> Reading the log file, we at least have one bug in Orca itself (a Python
>> "NameError").  I am not entirely sure whether this bug triggers the
>> "hung" process or the "hung" process triggers the "NameError".
> Not sure if you (Niels) looked at the code, but when I look at it, that
> NameError is something that is not uncommon to happen as the whole
> exception handling is written exactly to handle that:
> https://sources.debian.net/src/gnome-orca/3.22.2-2/src/orca/generator.py/#L233
> The "hung" happens in the exception handling (which in itself is also in
> a try/except block). To me (but I am not very good in Python and not at
> all familiar with Orca) it still looks like synaptic is doing something
> that in the end triggers a time out. I hope somebody with more Python
> and/or Orca knowledge can shine a light on this.
> Paul

Hi Paul,

I had a brief look at the code and:

 * You are right that the NameError is expected.  It appears to be some
   method for lazily loading/evaluating values.

 * The actual issue is the other stacktrace.

 * The exception appears to be thrown from accessing an attribute.  I am
   assuming that object/attribute is a reference to an GUI object in
   the synaptic process using a GLib/GTK protocol.

 * I have not seen that error before, but codesearch.d.n helpfully
   points us to [1].

 * From that, I found [2], which suggests atspi concludes synaptic to be
   hung because it does not respond to a dbus "ping" call to
   "org.freedesktop.DBus.Peer".  Not that it makes me any wiser as to
   why the problem occurs.

Time to hunt for some dbus experts who can tell us why a process might
fail to respond to a ping.




More information about the pkg-gnome-maintainers mailing list