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. Thanks, ~Niels [1]: https://sources.debian.net/src/at-spi2-core/2.22.0-5/atspi/atspi-misc.c/?hl=1080#L1080 [2]: https://sources.debian.net/src/at-spi2-core/2.22.0-5/atspi/atspi-misc.c/?hl=1080#L1028
