Bug 95740 – [GTK] Crash in AccessibilityObject::accessibilityPlatformIncludesObject()

• Component: Accessibility
• Status: RESOLVED FIXED

[Joanmarie Diggs]

Just came across this. Investigating....

Thread 1 (Thread 0x7fffef3249c0 (LWP 2627)):
#0  0x00007ffff785a036 in WebCore::AccessibilityObject::accessibilityPlatformIncludesObject() const ()
   from /opt/gnome/lib64/libwebkitgtk-3.0.so.0
#1  0x00007ffff69256d9 in WebCore::AccessibilityMenuListPopup::accessibilityIsIgnored() const ()
   from /opt/gnome/lib64/libwebkitgtk-3.0.so.0
#2  0x00007ffff6926b0e in WebCore::AccessibilityObject::parentObjectUnignored() const ()
   from /opt/gnome/lib64/libwebkitgtk-3.0.so.0
#3  0x00007ffff78644b5 in webkitAccessibleGetIndexInParent(_AtkObject*) ()
   from /opt/gnome/lib64/libwebkitgtk-3.0.so.0
#4  0x00007ffff003b2e8 in impl_GetIndexInParent (bus=<optimized out>, message=0x1850ef0, user_data=0x1b1da30)
    at accessible-adaptor.c:226
#5  0x00007ffff0039991 in handle_other (pathstr=0x19bc088 "/org/a11y/atspi/accessible/240", member=<optimized out>, 
    iface=0x19bc0c0 "org.a11y.atspi.Accessible", path=0x703f30, message=0x1850ef0, bus=0x19d11d0) at droute.c:538
#6  handle_message (bus=0x19d11d0, message=0x1850ef0, user_data=0x703f30) at droute.c:585
#7  0x00000033b801d685 in ?? () from /lib64/libdbus-1.so.3
#8  0x00000033b800f90d in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#9  0x00007fffefe10a15 in message_queue_dispatch (source=source@entry=0x1b19df0, callback=<optimized out>, 
    user_data=<optimized out>) at atspi-gmain.c:97
#10 0x00007ffff029e5c5 in g_main_dispatch (context=0x702810) at gmain.c:2715
#11 g_main_context_dispatch (context=context@entry=0x702810) at gmain.c:3219
#12 0x00007ffff029e8f8 in g_main_context_iterate (context=context@entry=0x702810, block=block@entry=1, 
    dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3290
#13 0x00007ffff029e9b4 in g_main_context_iteration (context=0x702810, context@entry=0x0, may_block=may_block@entry=1)
    at gmain.c:3351
#14 0x00007ffff12d7f6c in g_application_run (application=0x839000, argc=argc@entry=1, argv=argv@entry=0x7fffffffd938)
    at gapplication.c:1607
#15 0x00000000004306c4 in main (argc=1, argv=0x7fffffffd938) at ephy-main.c:499

[Joanmarie Diggs]

Seems we need a sanity check here:

--- a/Source/WebCore/accessibility/gtk/AccessibilityObjectAtk.cpp
+++ b/Source/WebCore/accessibility/gtk/AccessibilityObjectAtk.cpp
@@ -104,7 +104,7 @@ AccessibilityObjectInclusion AccessibilityObject::accessibilityPlatformIncludesO
     // anonymous blocks which are aria-related to themselves have an aria role, nor
     // have we encountered instances where the parent of an anonymous block also lacked
     // an aria role but the grandparent had one.
-    if (renderer()->isAnonymousBlock() && !parent->renderer()->isBody()
+    if (renderer() && renderer()->isAnonymousBlock() && !parent->renderer()->isBody()
         && parent->ariaRoleAttribute() == UnknownRole)
         return IgnoreObject;

My bad.

I still need to come up with a layout test that reproduces this scenario. (It's triggered by an AT poking at objects, e.g. looking for the next Heading for structural navigation, and coming across an object that lacks a renderer.)

[Martin Robinson]

(In reply to comment #1)

> My bad.
> 
> I still need to come up with a layout test that reproduces this scenario. (It's triggered by an AT poking at objects, e.g. looking for the next Heading for structural navigation, and coming across an object that lacks a renderer.)

You can also write a unit test if it would be easier.

[Joanmarie Diggs]

(In reply to comment #2)
> (In reply to comment #1)
> 
> > My bad.
> > 
> > I still need to come up with a layout test that reproduces this scenario. (It's triggered by an AT poking at objects, e.g. looking for the next Heading for structural navigation, and coming across an object that lacks a renderer.)
> 
> You can also write a unit test if it would be easier.

I thought I had a reliable layout test. Nope. Doesn't crash all the time.

Coming up with an automated test that only requires ATK (rather than AT-SPI along with an AT) is proving challenging. Came up with a different test case for the same problem. Will try it and unit-style. But I am reaching the point where I will accept pity too. ;) It's a sanity check which solves a crasher and it could be fixed if only I could come up with a magical test. :-/

Thread 1 (Thread 0x7f8906bf49c0 (LWP 20147)):
#0  0x00007f890b81b0a6 in WebCore::AccessibilityObject::accessibilityPlatformIncludesObject() const ()
   from /home/jd/checkout/WebKit/WebKitBuild/Release/.libs/libwebkitgtk-3.0.so.0
#1  0x00007f890a8a0439 in WebCore::AccessibilityMenuListPopup::accessibilityIsIgnored() const ()
   from /home/jd/checkout/WebKit/WebKitBuild/Release/.libs/libwebkitgtk-3.0.so.0
#2  0x00007f890b81e74b in webkitAccessibleHypertextGetNLinks(_AtkHypertext*) ()
   from /home/jd/checkout/WebKit/WebKitBuild/Release/.libs/libwebkitgtk-3.0.so.0
#3  0x00007f88fff2a868 in impl_GetNLinks (bus=<optimized out>, message=0x112ae00, user_data=0x11f3e30)
    at hypertext-adaptor.c:42
#4  0x00007f88fff248d1 in handle_other (pathstr=0x112b818 "/org/a11y/atspi/accessible/77", member=<optimized out>, 
    iface=0x112b850 "org.a11y.atspi.Hypertext", path=0x100c640, message=0x112ae00, bus=0x1018c00) at droute.c:538
#5  handle_message (bus=0x1018c00, message=0x112ae00, user_data=0x100c640) at droute.c:586
#6  0x00000033b801d685 in ?? () from /lib64/libdbus-1.so.3
#7  0x00000033b800f90d in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#8  0x00007f88ffcfa735 in message_queue_dispatch (source=source@entry=0x100b030, callback=<optimized out>, 
    user_data=<optimized out>) at atspi-gmain.c:97
#9  0x00007f8906ed4275 in g_main_dispatch (context=0xee00c0) at gmain.c:2539
#10 g_main_context_dispatch (context=context@entry=0xee00c0) at gmain.c:3075
#11 0x00007f8906ed45a8 in g_main_context_iterate (context=0xee00c0, block=block@entry=1, dispatch=dispatch@entry=1, 
    self=<optimized out>) at gmain.c:3146
#12 0x00007f8906ed49a2 in g_main_loop_run (loop=0x10ea460) at gmain.c:3340
#13 0x00007f8908ef1ee5 in gtk_main () at gtkmain.c:1161
#14 0x0000000000403969 in main ()

[Joanmarie Diggs]

<laughing insanely, but cheerfully />

Reliably reproducible crasher by adding a check to one of our unit tests! 
(Patch to follow)

Thread 1 (Thread 0x7ffff15d79c0 (LWP 24453)):
#0  0x00007ffff71f6056 in WebCore::AccessibilityObject::accessibilityPlatformIncludesObject() const ()
   from /home/jd/checkout/gnome/WebKit/.libs/libwebkitgtk-3.0.so.0
#1  0x00007ffff62c1499 in WebCore::AccessibilityMenuListOption::accessibilityIsIgnored() const ()
   from /home/jd/checkout/gnome/WebKit/.libs/libwebkitgtk-3.0.so.0
#2  0x00007ffff71f96fb in webkitAccessibleHypertextGetNLinks(_AtkHypertext*) ()
   from /home/jd/checkout/gnome/WebKit/.libs/libwebkitgtk-3.0.so.0
#3  0x000000000040b092 in testWebkitAtkComboBox ()
#4  0x00007ffff1cc9cf5 in test_case_run (tc=0x74f430) at gtestutils.c:1679
#5  g_test_run_suite_internal (suite=suite@entry=0x696520, path=<optimized out>, path@entry=0x7ffff1d3e1be "")
    at gtestutils.c:1732
#6  0x00007ffff1cc9e76 in g_test_run_suite_internal (suite=suite@entry=0x696540, path=<optimized out>, 
    path@entry=0x7ffff1d3e1be "") at gtestutils.c:1743
#7  0x00007ffff1cc9e76 in g_test_run_suite_internal (suite=suite@entry=0x696620, path=<optimized out>, 
    path@entry=0x7ffff1d3e1be "") at gtestutils.c:1743
#8  0x00007ffff1cca1db in g_test_run_suite (suite=0x696620) at gtestutils.c:1788
#9  0x0000000000402c62 in main ()

[Joanmarie Diggs]

Created attachment 162067 [details]
Patch

[Martin Robinson]

Comment on attachment 162067 [details]
Patch

Do you mind also adding this to the list of proposed merges for the 1.10.x series? https://trac.webkit.org/wiki/WebKitGTK/1.10.x

[WebKit Review Bot]

Comment on attachment 162067 [details]
Patch

Clearing flags on attachment: 162067

Committed r127483: <http://trac.webkit.org/changeset/127483>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.