Seems like the speech dispatcher threads are unrelated and the hang happens inside atspi.

I added some debugging code to at-spi2-core, atspi-text.c, AtspiTextRange *atspi_text_get_text_at_offset.

It displays the following:

entering gettext, object: 0xb6f588e9
calling dbus
returned from dbus
entering gettext, object: 0xb6f588e9
calling dbus

Before pressing KP_8 there is no call to get_text_at_offset. Then 2 calls are made, the first one returns, the second one seems to hang on dbus.

I am using at-spi2-core and at-spi2-atk from latest git (2013-09-05).

Passing it to at-spi, hopefully a correct action.

I'm seeing a crash in gtk (for some reason, orca starts to use 100% of cpu cycles when it crashes, rather than dying), so I'm guessing that it's what you're running into:

(gdb) bt full

+ Trace 232459

I'm not sure if _gtk_pango_get_text_at should just check that pango_layout_get_text hasn't returned NULL, or if something deeper is going wrong.

Mike, thanks for checking that and for showing me new useful debugging methods: gdb and bt full.

I only get a segfault in gtk-3.0, probably because I don't have source code for gtk. But I confirm seeing that crash. What do we do now?

When testing with orca please do not use latest commit which removes calls to threads_init. I suffer from strange problems after this commit. Fortunately this bug is not affected by this. So my current orca version is "git checkout 2741abd28b10864d3342190ce6f583c1d3fe4345".

Moving to gtk.

Also, what version of glib2 are you using?

I am at debian unstable, that is version of package libgtk-3-0 is 3.8.2-3.

After muting this violation in pango orca seems to be totally lost in the labels it speaks. It speaks the same label on many rows, and it is a label of the row that is not on the screen. Probably that has something to do with the scroll bar in the long table.

Please wait with investigation inside gtk, because it's possible that orca provides malformed parameters to its atspi calls. I'll test it more thoroughly and report again.

My analyze (I am a gtk newbie) confirms what Joanmarie said in 707729, that there is a bug in gtk. If the PangoLayout is created and the "text" member is not set, then "text"
remains null. This happens for example in gtk_widget_create_pango_layout.

So calls to pango_layout_get_text should not assume it always returns non null pointer. However numerous calls to this function in gtkpango seem to assume, that the pointer is never null.

Another way of fixing this null problem would be to assume that the layouts gtk creates are always filled with text. But this assumption is broken by gtk_widget_create_pango_layout, which does not set text at all. I tested that if pango_layout_set_text is called with a null parameter, the text is set to an empty string. So the following code does not crash, but prints "text: ":

#include <pango/pango.h>

main()
{
  gtk_init(NULL, NULL);
  PangoContext *pcont = pango_context_new();
  PangoLayout *play = pango_layout_new(pcont);
  //pango_layout_set_text(play, "some text", 9);
  pango_layout_set_text(play, NULL, 0);
  printf("text: %s\n", pango_layout_get_text(play));
  g_object_unref(play);
  g_object_unref(pcont);
  return 0;
}


comment on 707729 bug: https://bugzilla.gnome.org/show_bug.cgi?id=707729#c1
some handy source links:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkpango.c
https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c
https://git.gnome.org/browse/pango/tree/pango/pango-layout.c
https://git.gnome.org/browse/gtk+/tree/gtk/a11y/gtktextcellaccessible.c

Thanks, Benjamin.

I guess this is the right link of the fix commit:

https://git.gnome.org/browse/pango/commit/pango/pango-layout.c?id=114d5bfe9d54d1efabc233312d2c23267cf16f59