The code causing problems in my app is in "src/foldercontent.c"

static void folder_content_delete_file( FolderContent* content,
                                                                        const char* filename );

static gboolean on_fam_event(GIOChannel *channel,
                                                      GIOCondition cond,
                                                      gpointer user_data );

When monitored files on disk are deleted (notified by FAM), I have to 
update the GtkTreeView.
So I install a idle handler with g_idle_add.

Then the handler which will update all folder views is called.
static gboolean call_update_callback( gpointer data );

The update_callback then calls
gboolean update_folder_view_visible_region( FileBrowserData* data )
in src/filebrowser.c

Then, the app crashes because GtkTreeView returns some invalid GtkTreeIters.
(Cause by the preceding problems I described)

In my app, gtk_tree_view_get_visible_range sometimes returns invalid paths, too.
I believe that they are cause by the same problems, the underlying GtkTreeModelSort.
Please help me. After these problems are solved, my app will be a good file manager and 
one of the best demonstration of the power of GtkTreeView/GtkTreeModel.

There is no need at all to wrap a list store in a GtkTreeModelSort,
since the liststore is sortable itself.

(In reply to comment #2)
> There is no need at all to wrap a list store in a GtkTreeModelSort,
> since the liststore is sortable itself.
> 
There ``IS'' need if you have ``large set of data''.
Without GtkTreeModelSort, you cannot share the same model between different views, 
if the view items are displayed in different order.
Sort the GtkListStore itself will affect ``ALL'' view diaplaying it.

Using different GtkListStore for different views is a bad idea 
when the list is very large.  This not only greatly increase memory usage, 
but also greatly increase the view creation time 
(Since each view have to create its own list store, and cannot share existing models).
This will induce great performance hit if the large list is created form on-disk files 
or database since the I/O operations are dramatically increased.
Cache the list myself in memory is not a good idea because I have to keep an additional
list to hold all data beside those inside GtkListStores.

If the model is changed in one view, developers will have to synchronize the changes
by themselves between all these duplicated lists.  And this is really a very bad idea.

That's why we need GtkTreeModelSort.
According to GTK+ API doc:
The primary purpose of this model is to provide a way to sort a different model without modifying it.

This is very important.
Using GtkTreeSortable interface has nothing to do with wrapping a GtkListStore with a 
GtkTreeModelSort.  They are totally different thing and serve different needs.

After tracing, I found the problem.
In gtk_tree_model_sort_row_deleted, there is several lines:

  if ( level->ref_count == 0 )
  {
    /* This will prune the level, so I can just emit the signal and
     * not worry about cleaning this level up.
     * Careful, root level is not cleaned up in increment stamp.
     */
    ptk_tree_model_sort_increment_stamp ( tree_model_sort );
    gtk_tree_path_free ( path );
    if ( level == tree_model_sort->root )
    {
      ptk_tree_model_sort_free_level ( tree_model_sort,
                                       tree_model_sort->root );
      tree_model_sort->root = NULL;
    }
    return ;
  }

I found level->ref_count seems to be always 0, and this cause the problem.
After any row is deleted, ``level'' always gets freed.
Hence when aother row in the same level are deleted, there is no ``level'', 
and then ptk_real_tree_model_sort_convert_child_path_to_path cannot 
convert s_path to path since there is no information about current level. 
(level and its internal array has been freed and this shouldn't happen)

So that's why when several rows are deleted at the same time, only the first 
deleted row can correctly emit "row-deleted" signal to its parent.

If you guys can get level->ref_count correctly counted, the bug can be fixed.

I have encountered exact the same thing mentioned above. Where the patch supplied by HJ Yee works perfect for me.

oops, just realized that it wasn't a patch but just the correction in comment #4.

Compiled pcmanfm (cvs versions HEAD, Jan 28, Jan 25 and Jan 23) against gtk+ HEAD and the problems did not occur.   I assume the problems have been solved by the GtkTreeModelFilter rewrite and GtkTreeModelSort bugfixes in HEAD, if this appears not to be the case later on, please reopen the bug.