I never experienced this crash until I updated my GTK+ to master so I suspect this could be a GTK+ regression.

Two questions:

  1) Is this assertion hit every time you try to set the presence to offline using the shell?  (i.e. is it reliably reproducible that way?)

  2) When did you update GTK+ to master / what is the HEAD commit you are running with?

With question 2, I meant to verify whether you were at least running master from September 12.

The assertion you are hitting basically means that GtkTreeModelFilter's root level has been freed, however, the root zero_ref_count is still > 0 where it should be 0.  Likely, something is not being released properly somewhere or the zero_ref_count is being erroneously increased.

I will need more information to solve this problem, so I would like to request the following:

 - Update GTK+ master to today's top of tree (should include commit e1ede022f87e6fe7c2d4be29e61ce9be8866d24f).

 - In gtk/gtktreemodelfilter.c, enable MODEL_FILTER_DEBUG at line 328. This will enable more assertions.

 - Run Empathy against this GTK+ and give a backtrace of where it crashes.  It is very well possible it will crash at another place (hopefully where the faulty condition is introduced).

  - If it again crashes with gtk_tree_model_filter_row_deleted() in the stack, like frame #7 in trace 228443 which you provided, please include the following data from that exact frame:

print *filter->priv
print *elt
print *level

In general, this data is very useful also if you have another likewise function in your stack like gtk_tree_model_filter_row_inserted(), gtk_tree_model_filter_remove_elt_from_level(), etc.

(In reply to comment #2)
> Two questions:
> 
>   1) Is this assertion hit every time you try to set the presence to offline
> using the shell?  (i.e. is it reliably reproducible that way?)

No, it wasn't 100% reproducible.

>   2) When did you update GTK+ to master / what is the HEAD commit you are
> running with?

I updated my HEAD to 68e943506e411b0accce1fd0b6fa6eece23c4ac8 and still observed this bug. The trace was the same with MODEL_FILTER_DEBUG enabled.


(gdb) print *filter->priv
$1 = {child_model = 0x79ec80, root = 0x0, virtual_root = 0x0, stamp = 1906367665, child_flags = 1, zero_ref_count = 1, 
  visible_column = -1, visible_func = 0x4df568 <individual_view_filter_visible_func>, visible_data = 0xaf8060, 
  visible_destroy = 0, modify_types = 0x0, modify_func = 0, modify_data = 0x0, modify_destroy = 0, modify_n_columns = 0, 
  visible_method_set = 1, modify_func_set = 1, in_row_deleted = 0, virtual_root_deleted = 0, changed_id = 592, 
  inserted_id = 593, has_child_toggled_id = 594, deleted_id = 595, reordered_id = 596}
(gdb) print *elt
$2 = {iter = {stamp = 19475264, user_data = 0x0, user_data2 = 0x0, user_data3 = 0x0}, children = 0x0, offset = 0, 
  ref_count = 0, ext_ref_count = 0, zero_ref_count = 0, visible_siter = 0x1283800}
(gdb) print *level
$3 = {seq = 0x6f69747265737361, visible_seq = 0x64656c696166206e, ref_count = 1814569018, ext_ref_count = 1818588773, 
  parent_elt = 0x29, parent_level = 0x0}

priv->root is NULL and priv->zero_ref_count is 1, that shouldn't happen AFAIK. Surely a refcount issue somewhere... :/

When you enable MODEL_FILTER_DEBUG, are you sure the assert happens at the same place? Looking at code, it should assert sooner because it always verify that priv->zero_ref_count==0 when setting priv->root to NULL.

Humm sorry actually I wasn't testing with MODEL_FILTER_DEBUG. Here is the new trace:


Gtk:ERROR:gtktreemodelfilter.c:1012:gtk_tree_model_filter_free_level: assertion failed: (filter->priv->zero_ref_count == 0)

Program received signal SIGABRT, Aborted.
0x00007fffec6ebd05 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	../nptl/sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce type.
	in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt full

+ Trace 228487

Oh, and I get those 2 warnings before the crash:

(empathy:9809): Gtk-CRITICAL **: gtk_tree_path_compare: assertion `b->depth > 0' failed

(empathy:9809): Gtk-CRITICAL **: gtk_tree_path_compare: assertion `b->depth > 0' failed
**

(In reply to comment #8)
> Oh, and I get those 2 warnings before the crash:
> 
> (empathy:9809): Gtk-CRITICAL **: gtk_tree_path_compare: assertion `b->depth >
> 0' failed
> 
> (empathy:9809): Gtk-CRITICAL **: gtk_tree_path_compare: assertion `b->depth >
> 0' failed
> **

May not be related actually. I just got the crash again without the warnings now.

I'm wondering if bug #659441 could have an influence on this, since it is related to removing rows too... But for what I understand of that code, it shouldn't be an issue.

(In reply to comment #10)
> I'm wondering if bug #659441 could have an influence on this, since it is
> related to removing rows too... But for what I understand of that code, it
> shouldn't be an issue.

Nope; I still got this bug with your fix.

(In reply to comment #5)
> priv->root is NULL and priv->zero_ref_count is 1, that shouldn't happen AFAIK.
> Surely a refcount issue somewhere... :/

That is correct -- I pointed this out in comment 3.

(In reply to comment #7)
> Gtk:ERROR:gtktreemodelfilter.c:1012:gtk_tree_model_filter_free_level: assertion
> failed: (filter->priv->zero_ref_count == 0)
> 
> Program received signal SIGABRT, Aborted.
> 0x00007fffec6ebd05 in raise (sig=6) at


So basically, we are missing a decrement of the zero ref count (or an increment too many) and this is affecting the clean up of the root level when the last node is removed.   I will think about a scenario in which this happen so we can set up a unit test.

(In reply to comment #8)
> (empathy:9809): Gtk-CRITICAL **: gtk_tree_path_compare: assertion `b->depth >
> 0' failed

For the record, I filed Bug #659877 about this assertion.

Created attachment 198085 [details]
stand-alone test case which reliably reproduces the bug

This is a stand-alone test case which reliably triggers the faulty condition.  The test case is basically a model of what EmpathyIndividualStore and EmpathyIndividualView are doing.

Now debugging ...

Created attachment 198111 [details] [review]
Patch set fixing the problem

This patch set seems to solve the problems for me.  I will be writing stand-alone test cases for each separate fix before I will push this.

It would be appreciated if anyone is able to give this patch a try with the real empathy to see if the problem has indeed vanished.

Pushed to master, will push to gtk-3-2 shortly.

Thanks, I'll update my GTK+ and let you know if I experience this bug again.

*** Bug 660571 has been marked as a duplicate of this bug. ***

*** Bug 662754 has been marked as a duplicate of this bug. ***