Crash in filebrowser

[Andrius]

Time to time I am getting the crash in filebrowser when opening large project, with files located in several subfolders.

This error probably is related to the crash that was fixed in r8130 (there was exchange regarding that issue in late October).

The crash does not happens all the time, probably, in 80% of the starts it is loaded normally.

I am attaching log files when bluefish is loaded normally, and when crash happens. In crash file there is also backtrace.
In the files there are some extra g_print statements, that normally should not be there - I added them manually. ALso, this is development version of filebrowser2.c that uses different logic to mark bold opened files in the filebrowser, but I am sure that this should not cause this crash (actually the crash was happening time to time even before I introduced these changes).
I looks that now the crash happens after we emit row-delete signal and tree_model_filter is trying to do some rearrangement. It pickups some invalid iter in the process and then segfaults.
Andrius

[Olivier Sessink]

Post by Andrius
Time to time I am getting the crash in filebrowser when opening large
project, with files located in several subfolders.
This error probably is related to the crash that was fixed in r8130
(there was exchange regarding that issue in late October).
The crash does not happens all the time, probably, in 80% of the
starts it is loaded normally.
I am attaching log files when bluefish is loaded normally, and when
crash happens. In crash file there is also backtrace.
In the files there are some extra g_print statements, that normally
should not be there - I added them manually. ALso, this is development
version of filebrowser2.c that uses different logic to mark bold
opened files in the filebrowser, but I am sure that this should not
cause this crash (actually the crash was happening time to time even
before I introduced these changes).
I looks that now the crash happens after we emit row-delete signal and
tree_model_filter is trying to do some rearrangement. It pickups some
invalid iter in the process and then segfaults.
Andrius

I'm not sure about the tooling you have on OSX, but can you reproduce
this in a memory checker like valgrind or something similar? Or just
create a backtrace in a debugger?

Olivier

[Andrius]

Olivier,
on MacOSX there is gdb available, but I do not think that it will help here. When working on r8130 crashes dissapeared while running with gdb. Probably there are racing conditions and gdb adds extra latency.
The backtrace is in the crash log. I will put fragment of it here:
0   libgtk-3.0.dylib                  0x0000000110339307 gtk_tree_model_get_valist + 583
1   libgtk-3.0.dylib                  0x00000001103390aa gtk_tree_model_get + 554
2   bluefish-bin                      0x000000010fb0c93e tree_model_filter_func + 110
3   libgtk-3.0.dylib                  0x000000011033d11e gtk_tree_model_filter_real_visible + 78
4   libgtk-3.0.dylib                  0x000000011033d221 gtk_tree_model_filter_visible + 65
5   libgtk-3.0.dylib                  0x000000011033d56b gtk_tree_model_filter_check_ancestors + 331
6   libgtk-3.0.dylib                  0x000000011033fd9e gtk_tree_model_filter_row_deleted + 1486
7   libgobject-2.0.0.dylib            0x0000000110c8a14d g_cclosure_marshal_VOID__BOXED + 237
8   libgobject-2.0.0.dylib            0x0000000110c841f2 g_closure_invoke + 546
9   libgobject-2.0.0.dylib            0x0000000110caade8 signal_emit_unlocked_R + 1816
10  libgobject-2.0.0.dylib            0x0000000110ca9a98 g_signal_emit_valist + 6072
11  libgobject-2.0.0.dylib            0x0000000110caa404 g_signal_emit + 372
12  libgtk-3.0.dylib                  0x0000000110339d05 gtk_tree_model_row_deleted + 261
13  bluefish-bin                      0x000000010fb08abf ftm_remove + 991
14  bluefish-bin                      0x000000010fb08be4 ftm_delete_children + 116
15  bluefish-bin                      0x000000010fb08d10 enumerator_close_lcb + 128

After row-deleted signal is emitted all of functions are stock gtk functions, except tree_model_filter_func in filebrowser2.c . I am able to avoind crashes by putting into this functions iter validity check like this

if (iter == NULL || iter->user_data == NULL || iter->stamp != filetreemodel(model)->stamp) {
        g_warning("tree_model_filter_func, called with invalid iter %p, iter_userdata=%p, iter stamp =%d\n",iter, iter->user_data, iter->stamp);
        return FALSE;
    }
in front of gtk_tree_model_get(). No visible effects on operation of bf with this patch, however, now I can continue to work.

I also found more details when this crash happens. There is situation during opening of the project when basedir (and root of the tree_model) is changed on the fly - if currently active file is outside of the basedir of the project. In the beginning project sets basedir and starts refesh of it, and then, when we focus to the file that is active plus outside the basedir, the basedir is reset and new refresh is started. So, to see this error You need project with special configuration. I will try to get more clues what might be causing this crash.
Andrius

________________________________
I'm not sure about the tooling you have on OSX, but can you

reproduce this in a memory checker like valgrind or something
similar? Or just create a backtrace in a debugger?

[Olivier Sessink]

Post by Andrius
Olivier,
on MacOSX there is gdb available, but I do not think that it will help
here. When working on r8130 crashes dissapeared while running with
gdb. Probably there are racing conditions and gdb adds extra latency.
0 libgtk-3.0.dylib 0x0000000110339307
gtk_tree_model_get_valist + 583
1 libgtk-3.0.dylib 0x00000001103390aa
gtk_tree_model_get + 554
2 bluefish-bin 0x000000010fb0c93e
tree_model_filter_func + 110
3 libgtk-3.0.dylib 0x000000011033d11e
gtk_tree_model_filter_real_visible + 78
4 libgtk-3.0.dylib 0x000000011033d221
gtk_tree_model_filter_visible + 65
5 libgtk-3.0.dylib 0x000000011033d56b
gtk_tree_model_filter_check_ancestors + 331
6 libgtk-3.0.dylib 0x000000011033fd9e
gtk_tree_model_filter_row_deleted + 1486
7 libgobject-2.0.0.dylib 0x0000000110c8a14d
g_cclosure_marshal_VOID__BOXED + 237
8 libgobject-2.0.0.dylib 0x0000000110c841f2
g_closure_invoke + 546
9 libgobject-2.0.0.dylib 0x0000000110caade8
signal_emit_unlocked_R + 1816
10 libgobject-2.0.0.dylib 0x0000000110ca9a98
g_signal_emit_valist + 6072
11 libgobject-2.0.0.dylib 0x0000000110caa404 g_signal_emit
+ 372
12 libgtk-3.0.dylib 0x0000000110339d05
gtk_tree_model_row_deleted + 261
13 bluefish-bin 0x000000010fb08abf ftm_remove + 991
14 bluefish-bin 0x000000010fb08be4
ftm_delete_children + 116
15 bluefish-bin 0x000000010fb08d10
enumerator_close_lcb + 128
After row-deleted signal is emitted all of functions are stock gtk
functions, except tree_model_filter_func in filebrowser2.c . I am able
to avoind crashes by putting into this functions iter validity check
like this
if (iter == NULL || iter->user_data == NULL || iter->stamp !=
filetreemodel(model)->stamp) {
g_warning("tree_model_filter_func, called with invalid iter
%p, iter_userdata=%p, iter stamp =%d\n",iter, iter->user_data,
iter->stamp);
return FALSE;
}
in front of gtk_tree_model_get(). No visible effects on operation of
bf with this patch, however, now I can continue to work.

what I think I understand from your log: the 'row-delete' signal that
we trigger will fire a 'refilter'. But directly after the row-delete we
free the entry (and thus the iter is no longer valid). The tree refilter
takes place after we have free'ed the entry that the iter points to.

Could this be happening? That sounds like a bug in gtk....? Or did we
implement something wrong?

Olivier

[Olivier Sessink]

Post by Andrius
Time to time I am getting the crash in filebrowser when opening large
project, with files located in several subfolders.
This error probably is related to the crash that was fixed in r8130
(there was exchange regarding that issue in late October).
The crash does not happens all the time, probably, in 80% of the
starts it is loaded normally.
I am attaching log files when bluefish is loaded normally, and when
crash happens. In crash file there is also backtrace.
In the files there are some extra g_print statements, that normally
should not be there - I added them manually. ALso, this is development
version of filebrowser2.c that uses different logic to mark bold
opened files in the filebrowser, but I am sure that this should not
cause this crash (actually the crash was happening time to time even
before I introduced these changes).
I looks that now the crash happens after we emit row-delete signal and
tree_model_filter is trying to do some rearrangement. It pickups some
invalid iter in the process and then segfaults.
Andrius

can you enable DBG_FILTERSORT in filebrowser2.c and together with the
debugging in file_treemodel.c and reproduce it again? That will give a
bit more insight which iter is invalid.

Olivier

[Olivier Sessink]

Post by Olivier Sessink
can you enable DBG_FILTERSORT in filebrowser2.c and together with the
debugging in file_treemodel.c and reproduce it again? That will give a
bit more insight which iter is invalid.
Olivier

b.t.w. I wonder if changing filebrowser2.c line 504 to FALSE would solve
the problem. Can you test that?

Olivier