So yeah, Empathy just uses gtk_list_store_append() and then gtk_list_store_set().
But the data_func function of the GtkCellRendererPixbuf is now called during the_append(). As this function relies on the data which have not been set yet it crashes.

So, does Empathy should cope with the data not being set yet or should Gtk+ not call the cell data func until they have been set?

Interesting, I updated to Gtk+ master and can't reproduce this bug.

Created attachment 208198 [details]
is there an off by one in the row indice for gtktreeviewaccessible 

I made up this local change to workaround the issue (ie I remove the added one to the row index - not confident this is right : there is already one added to the n_rows to account for the new row. I cannot seem to find out if the indice in the loop is suppose to start from zero - what I did - or one - what was there). 
My experiment leads to first _gtk_tree_view_accessible_add fails as it does not manage to get the accessible. Issue start with second add (second account).
Also accessibility is involved. I don't know if with it disabled gtktreeviewaccessible is reached at all.
The data_func calls is triggered in _gtk_tree_view_accessible_add  by:
  g_signal_emit_by_name (accessible, "children-changed::add", i, NULL, NULL);

Created attachment 208199 [details]
is there an off by one in gtktreeviewaccessible

Re-assigning to Gtk+ to see what gtk dev think about this.

So what's happening (In reply to comment #3)
> Created an attachment (id=208198) [details]
> is there an off by one in the row indice for gtktreeviewaccessible 
> 
That patch is wrong - the addition of the one is needed because the first row in the accessible contains the headers. You are right that it does work around the bug though, because it will then only emit signals for the seond-to-last row, which you already have set up fine.

So, what's happening here is that the treeview a11y code is emitting a signal "a row was just added" and then the accessible bridge comes and asks "and what are its contents so I can send them to Orca?" in children_changed_event_listener().

And I don't see another place to do this - other then when a row was added. So I think it should be empathy that handles this case - preferably using gtk_list_store_insert_with_values().

Bug disappeared since I updated my jhbuild. Hard to track which layer had the code that phased out the issue. Thanks.

Afraid I am reopening. I can still reproduce this problem, including in a fresh jhbuild environment. And from a look at this bug's history, it was closed as FIXED based on WFM rather than any changes being made and without knowing which module fixed it.

In order to reproduce the crasher, it seems you need to have an assistive technology actively listening for events. It can be something as simple as the following:

-------------------------------
#!/usr/bin/python
import pyatspi

def listener(e):
    pass

pyatspi.Registry.registerEventListener(listener, "object:state-changed:showing")
pyatspi.Registry.start()
-------------------------------

Run the above first. with it running, launch empathy-accounts. I get a segfault 100% of the time. Without anything listening, empathy-accounts works as expected.

Created attachment 210828 [details]
new backtrace

Sorry for the spamorama. Having chatted with Benjamin about this, transferring back to Empathy.

Thanks for your help guys. I'm working on a fix.

Created attachment 210866 [details] [review]
accounts-dialog: use gtk_list_store_insert_with_values()

Prevent a crash when using a11y as GTK+ may want to look at the content of the
row as soon it's added. See the bug for details.

Attachment 210866 [details] pushed as 889cbf1 - accounts-dialog: use gtk_list_store_insert_with_values()

Fix verified. Orca users will be pleased. :) Thanks Guillaume!!