[orca-list] Update on the situation with closing apps hanging Orca: Please resume testing

[Joanmarie Diggs <jdiggs igalia com>]

Hey again.

This is a good-news, bad-news situation. The good news is that I figured
out why Orca was hanging when AT-SPI2 performed an illegal operation or
the registry crashed. Orca was trying to gracefully handle that
situation. Turns out one should not try to catch synchronous errors that
come from C code. Live and learn. Having removed that handler, Orca will
now crash rather than hang if AT-SPI2 spits up on us. It won't say
goodbye; it will just die. It will also dump out a brief traceback
indicating where the crash occurred. This will hopefully help us to
narrow down where things are failing. That is the good(ish) news.

The bad news is that I've been trying really hard to figure out what
exactly is causing AT-SPI2 to spit up and stop Orca from doing whatever
those things are. That way, Orca would not only not hang, but it would
not crash either. So far, I've not had much luck. As those of you who
have reported the problems have stated, some times it happens; some
times it doesn't. And what the steps to reproduce are can vary. This is
looking like something we need to get fixed in AT-SPI2. Which brings me
to the last thing:

Once again, I want your debug.outs -- captured when using the latest
master. Before you send it, however, please see if the crash is unique.
As an example, here is what I have at the end of my debug.out:

<start of error>
Stack (most recent call first):
  File "/usr/lib/python3.5/site-packages/pyatspi/Accessibility.py", line
56 in Accessible_str
  File "/usr/lib/python3.5/site-packages/orca/event_manager.py", line
248 in _queuePrintln
  File "/usr/lib/python3.5/site-packages/orca/event_manager.py", line
321 in _dequeue
  File "/usr/lib/python3.5/site-packages/pyatspi/registry.py", line 155
in start
  File "/usr/lib/python3.5/site-packages/orca/orca.py", line 575 in start
  File "/usr/lib/python3.5/site-packages/orca/orca.py", line 726 in main
  File "/usr/bin/orca", line 255 in main
  File "/usr/bin/orca", line 258 in <module>
<end of error>

Let's say I have three crashes from using three different apps or steps
to reproduce. If at the end of all three of my debug.out files I have
that very same stack from top to bottom, it's the same crash. It just
happened three times. What I'm interested in is unique crashes/stacks.
Obviously, Kendell won't know what Max's crashes are and vice versa. But
if you could send just those crashes which are unique for you, that
would be helfpul.

Please let me know if you have any questions, and thanks again for your
help in hunting these things down!

--joanie