gtktreestore.c:596:gtk_tree_store_get_path: assertion failed
reagentoo opened this issue · comments
Sunflower crashes when actively editing and saving files.
$ sunflower
(Sunflower:17462): Gtk-CRITICAL **: 11:20:15.376: gtk_tree_store_sort_iter_changed: assertion 'G_NODE (iter->user_data)->parent != NULL' failed
**
Gtk:ERROR:/var/tmp/portage/x11-libs/gtk+-3.24.22/work/gtk+-3.24.22/gtk/gtktreestore.c:596:gtk_tree_store_get_path: assertion failed: (G_NODE (iter->user_data)->parent != NULL)
Bail out! Gtk:ERROR:/var/tmp/portage/x11-libs/gtk+-3.24.22/work/gtk+-3.24.22/gtk/gtktreestore.c:596:gtk_tree_store_get_path: assertion failed: (G_NODE (iter->user_data)->parent != NULL)
Aborted
Can you elaborate on editing and saving part. You mean editing and saving files from a directory which Sunflower is looking at?
@MeanEYE Yes. I went to the directory with text files and am actively editing them (Using F4 - gedit). The file manager crashes.
I guess the problem in auto updating file list.
Can you provide details regarding those files. What are you editing them with. Can you reproduce with a different editor?
Sorry. Later I'll try to clarify the sequence of actions. At the moment it has ceased to occur for me.
I think this error is caused by FileMonitor.
Many downloaders and editors and other applications (even 'mv' of coreutils) create temporary files and remove them immediately, so the inotify event may occured during sorting.
view a (empty) directory and, in another terminal, call this code several times could also reproduce this error.:
for p in `seq 100`; do
touch a${p} && rm a${p} && touch a${p} && rm a${p}
doneOkay, thank you. What I think is going is that we are trying to update data on an iter that got removed in the mean time. However reaching this timing is really difficult. It's a racing condition between when item gets added to the list sorting mechanism gets to generate data for it while being removed in between. Then update fails because it's trying to assign data to non-existent iter.
How reliably can this be reproduced?
Almost every time, on AMD A10-9600P cpu, calling the code above, in a directory of tmpfs.
Maybe a high performance of disk IO (e.g. SSD/ramdisk/tmpfs) and a lower performance of CPU (e.g. low power CPU on laptop) will cause this error more easily.
This bug is very annoying. :(
I'll take a look as soon as I can and see if I can fix this.
@reagentoo does this issue not exist for you anymore?
@MeanEYE I've thought this issue had become an integral part of this FM and now I can't imagine life without a constantly falling application.
I still plan on fixing it. Issue shouldn't be closed unless it's resolved or invalid, which this one is neither.
@MeanEYE , hi
I'm constantly get sunflower's Segmentation fault when I'm saving files (no matter which editor).
(gdb) bt full
#0 gtk_tree_store_get_value (tree_model=<optimized out>, iter=<optimized out>, column=9, value=0x5555569671b0) at ../gtk+-3.24.38/gtk/gtktreestore.c:661
tree_store = <optimized out>
priv = 0x555556e3d6c0
list = 0xab94d8b
tmp_column = 8
__func__ = "gtk_tree_store_get_value"
#1 0x00007ffff7ea500a in () at /usr/lib64/libffi.so.8
#2 0x00007ffff7ea44ae in () at /usr/lib64/libffi.so.8
#3 0x00007ffff7ea4b9d in ffi_call () at /usr/lib64/libffi.so.8
#4 0x00007ffff6ed7eb3 in () at /usr/lib/python3.11/site-packages/gi/_gi.cpython-311d-x86_64-linux-gnu.so
#5 0x00007ffff6ed9f78 in () at /usr/lib/python3.11/site-packages/gi/_gi.cpython-311d-x86_64-linux-gnu.so
#6 0x00007ffff6ec5f29 in () at /usr/lib/python3.11/site-packages/gi/_gi.cpython-311d-x86_64-linux-gnu.so
#7 0x00007ffff79aa3bb in _PyObject_MakeTpCall () at /usr/lib64/libpython3.11d.so.1.0
#8 0x00007ffff7906e1c in _PyEval_EvalFrameDefault () at /usr/lib64/libpython3.11d.so.1.0
#9 0x00007ffff7ac59a6 in () at /usr/lib64/libpython3.11d.so.1.0
#10 0x00007ffff79adfc4 in () at /usr/lib64/libpython3.11d.so.1.0
#11 0x00007ffff6ed52a8 in () at /usr/lib/python3.11/site-packages/gi/_gi.cpython-311d-x86_64-linux-gnu.so
#12 0x00007ffff7ea4e25 in () at /usr/lib64/libffi.so.8
#13 0x00007ffff7ea51a0 in () at /usr/lib64/libffi.so.8
#14 0x00007ffff5c056a7 in gdk_threads_dispatch (data=0x555556fe1ee0) at ../gtk+-3.24.38/gdk/gdk.c:769
dispatch = 0x555556fe1ee0
ret = 0
#15 0x00007ffff6d9f609 in g_main_dispatch (context=0x5555557945f0) at ../glib-2.76.4/glib/gmain.c:3460
dispatch = 0x7ffff6d9ba10 <g_idle_dispatch>
prev_source = 0x0
begin_time_nsec = 0
was_in_call = 0
user_data = 0x555556fe1ee0
callback = 0x7ffff5c05680 <gdk_threads_dispatch>
cb_funcs = <optimized out>
cb_data = 0x555557048a50
need_destroy = <optimized out>
source = 0x555557035970
current = 0x555555794820
i = 0
__func__ = "g_main_dispatch"
#16 g_main_context_dispatch (context=context@entry=0x5555557945f0) at ../glib-2.76.4/glib/gmain.c:4200
#17 0x00007ffff6d9fa28 in g_main_context_iterate (context=context@entry=0x5555557945f0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib-2.76.4/glib/gmain.c:4276
max_priority = 200
timeout = 0
some_ready = 1
nfds = <optimized out>
allocated_nfds = 4
fds = 0x555556e79730
#18 0x00007ffff6d9fabc in g_main_context_iteration (context=context@entry=0x5555557945f0, may_block=may_block@entry=1) at ../glib-2.76.4/glib/gmain.c:4343
retval = <optimized out>
#19 0x00007ffff6b0b87d in g_application_run (application=0x555555cb07f0 [__main__+Sunflower], argc=1, argv=<optimized out>) at ../glib-2.76.4/gio/gapplication.c:2573
arguments = 0x555555cbdba0
status = 0
context = 0x5555557945f0
acquired_context = <optimized out>
__func__ = "g_application_run"
--Type <RET> for more, q to quit, c to continue without paging--
#20 0x00007ffff7ea500a in () at /usr/lib64/libffi.so.8
#21 0x00007ffff7ea44ae in () at /usr/lib64/libffi.so.8
#22 0x00007ffff7ea4b9d in ffi_call () at /usr/lib64/libffi.so.8
#23 0x00007ffff6ed7eb3 in () at /usr/lib/python3.11/site-packages/gi/_gi.cpython-311d-x86_64-linux-gnu.so
#24 0x00007ffff6ed9f78 in () at /usr/lib/python3.11/site-packages/gi/_gi.cpython-311d-x86_64-linux-gnu.so
#25 0x00007ffff79aa0b9 in _PyObject_Call () at /usr/lib64/libpython3.11d.so.1.0
#26 0x00007ffff7901e1c in _PyEval_EvalFrameDefault () at /usr/lib64/libpython3.11d.so.1.0
#27 0x00007ffff7ac59a6 in () at /usr/lib64/libpython3.11d.so.1.0
#28 0x00007ffff7ac5a6c in PyEval_EvalCode () at /usr/lib64/libpython3.11d.so.1.0
#29 0x00007ffff7ab9fe8 in () at /usr/lib64/libpython3.11d.so.1.0
#30 0x00007ffff7a08453 in () at /usr/lib64/libpython3.11d.so.1.0
#31 0x00007ffff79ab602 in PyObject_Vectorcall () at /usr/lib64/libpython3.11d.so.1.0
#32 0x00007ffff7906e1c in _PyEval_EvalFrameDefault () at /usr/lib64/libpython3.11d.so.1.0
#33 0x00007ffff7ac59a6 in () at /usr/lib64/libpython3.11d.so.1.0
#34 0x00007ffff7ac5a6c in PyEval_EvalCode () at /usr/lib64/libpython3.11d.so.1.0
#35 0x00007ffff7b19593 in () at /usr/lib64/libpython3.11d.so.1.0
#36 0x00007ffff7b198ea in () at /usr/lib64/libpython3.11d.so.1.0
#37 0x00007ffff7b19a20 in () at /usr/lib64/libpython3.11d.so.1.0
#38 0x00007ffff7b1d2e6 in _PyRun_SimpleFileObject () at /usr/lib64/libpython3.11d.so.1.0
#39 0x00007ffff7b1d970 in _PyRun_AnyFileObject () at /usr/lib64/libpython3.11d.so.1.0
#40 0x00007ffff7b41280 in Py_RunMain () at /usr/lib64/libpython3.11d.so.1.0
#41 0x00007ffff7b419ba in Py_BytesMain () at /usr/lib64/libpython3.11d.so.1.0
#42 0x00007ffff7650a0a in () at /lib64/libc.so.6
#43 0x00007ffff7650ac5 in __libc_start_main () at /lib64/libc.so.6
#44 0x0000555555555081 in _start ()
How else can I help with debugging?
Sorry for no progress on this. Best thing you can do is test for me as am having difficulty reproducing this. I'll try to look into this as soon as possible and then get back to you with prepared version for testing.
Thank you.
Okay, managed to narrow it down. _generate_sort_data method, which allows for complex sorting, is trying to access and mess around with data while they are being loaded. I should be able to find a solution to this now considering I know it's racing issue and where it occurs.
Finally fixed. Please reopen if you can still reproduce.