After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 777992 - crashes when screen reader Orca tries to read whole document
crashes when screen reader Orca tries to read whole document
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: general
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-01-31 17:04 UTC by Sebastian Humenda
Modified: 2017-03-27 09:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[GDB] full back trace (13.48 KB, text/x-log)
2017-01-31 17:04 UTC, Sebastian Humenda
  Details
Fix-crash-with-Orca-screen-reader.patch (1.14 KB, patch)
2017-03-22 04:40 UTC, Jason Crain
committed Details | Review
Return-correct-start-and-end-offsets.patch (2.44 KB, patch)
2017-03-27 00:54 UTC, Jason Crain
committed Details | Review

Description Sebastian Humenda 2017-01-31 17:04:42 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
Comment 1 Jason Crain 2017-03-22 04:40:57 UTC
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.
Comment 2 Joanmarie Diggs (IRC: joanie) 2017-03-22 18:17:47 UTC
(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.
Comment 3 Jason Crain 2017-03-22 19:50:56 UTC
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?
Comment 4 Joanmarie Diggs (IRC: joanie) 2017-03-24 07:31:27 UTC
(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 5 Carlos Garcia Campos 2017-03-26 09:19:47 UTC
Comment on attachment 348459 [details] [review]
Fix-crash-with-Orca-screen-reader.patch

This makes sense in any case, pushed. Thanks!
Comment 6 Jason Crain 2017-03-27 00:54:49 UTC
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 7 Carlos Garcia Campos 2017-03-27 09:24:21 UTC
Comment on attachment 348757 [details] [review]
Return-correct-start-and-end-offsets.patch

Thanks!