GNOME Bugzilla – Bug 777992
crashes when screen reader Orca tries to read whole document
Last modified: 2017-03-27 09:24:34 UTC
Created attachment 344655 [details] [GDB] full back trace Hello Evince repeatedly crashes due to ATK when using "say all" in the screen reader Orca. To reproduce, do the following: 1. Open a PDF, I've taken <https://www.gnu.org/ghm/2013/paris/slides/hurd--thibault--ghm-2013.pdf>. 2. Press Alt+F7 to activate caret browsing. 3. Press the key stroke to let Orca read the whole document, for laptop mode, that is capslock + arrow down. 4. After a few seconds, Evince crashes. The full backtrace is attached. Software versions: Evince 3.22.1, libatk-bridge2.0-0/libatspi2.0-0 2.22.0 Distribution: Debian (Stretch) Thanks
Created attachment 348459 [details] [review] Fix-crash-with-Orca-screen-reader.patch ev_page_accessible_get_substring is being called with out of bounds values. That's probably a bug in Orca, but it shouldn't crash evince. This patch clamps start_offset to be within a valid range.
(In reply to Jason Crain from comment #1) > Created attachment 348459 [details] [review] [review] > Fix-crash-with-Orca-screen-reader.patch > > ev_page_accessible_get_substring is being called with out of bounds values. > That's probably a bug in Orca, but it shouldn't crash evince. This patch > clamps start_offset to be within a valid range. I am now working around this issue in Orca, but I do believe the bug is in Evince. What happens in SayAll is that Orca asks for the text at offset for a given boundary. The return value is a string, startOffset, and endOffset. Orca speaks the string, and then asks for the text at endOffset. Rinse and repeat. When atspi_text_get_text_at_offset() is called at the end of the first slide, Orca asks for the sentence at offset 65. What it gets back via Evince is a single character '1' and an endOffset of 67. Turns out there are only 66 characters. Oops. Again, I am now sanity-checking the values Orca gets so that it doesn't ask for a value that is out of bounds. But if any other assistive technology (or AT-SPI2-based testing tool) were to trust the value it is being given by Evince for endOffset in this particular case, Evince would still crash. HTH.
I think evince might need to be changed to return 66 as the end offset at the end of the slide. It probably means changing a few '<=' to '<'. But then Orca will just request text at offset 66 next, right? So the function calls look like this: get_text_at_offset(48) -> (start=48, end=65, text="2013 August 24th") get_text_at_offset(65) -> (start=65, end=66, text="1") get_text_at_offset(66) -> ??? In that last case, is (start=66, end=66, text="") a good value?
(In reply to Jason Crain from comment #3) > I think evince might need to be changed to return 66 as the end offset at > the end of the slide. It probably means changing a few '<=' to '<'. But > then Orca will just request text at offset 66 next, right? So the function > calls look like this: > > get_text_at_offset(48) -> (start=48, end=65, text="2013 August 24th") > get_text_at_offset(65) -> (start=65, end=66, text="1") > get_text_at_offset(66) -> ??? > > In that last case, is (start=66, end=66, text="") a good value? That value makes sense to me. Thanks!
Comment on attachment 348459 [details] [review] Fix-crash-with-Orca-screen-reader.patch This makes sense in any case, pushed. Thanks!
Created attachment 348757 [details] [review] Return-correct-start-and-end-offsets.patch This patch fixes the start and end offsets returned by evince. Without this, it will sometimes return a start offset < 0, or an end offset past the end of the text.
Comment on attachment 348757 [details] [review] Return-correct-start-and-end-offsets.patch Thanks!