Nemo crashes with a coredump when trying to view an Empty folder (100% reproducible)

[nick-s-b]

 * Nemo version (nemo --version)
nemo 4.2.3

 * Is issue with desktop or windowed nemo?
Windowed
 * Distribution - (Mint 17.2, Arch, Fedora 25, etc...)
Arch
 * Graphics hardware *and* driver used
Nvidia, NVIDIA-SMI 440.31
 * 32 or 64 bit
64bit

Issue
This is an issue that's probably related to this bug that I managed to reproduce a while back and was fixed by @mtwebster : #2150 It too is related to how nemo handles "empty" folders. I think there's some other bug reports on here that are a variation of this bug but they're not really reproducible.

I've been experiencing this bug for a long time but couldn't reproduce it reliably. Initially, I also assumed it was the same bug as 2150 but it's clearly different since it persisted. I've finally found a series of steps that reproduce the coredump reliably and can be therefore investigated.

Typical coredump (click for the whole trace):

Dec 07 17:17:19 nsb systemd-coredump[560984]: Process 32358 (nemo) of user 1000 dumped core.

Stack trace of thread 32358:
#0  0x00007f957c71e965 gtk_tree_model_get_valist (libgtk-3.so.0)
#1  0x00007f957c71ec92 gtk_tree_model_get (libgtk-3.so.0)
#2  0x000055dd1eba3f96 n/a (nemo)
#3  0x00007f957c929c2e n/a (libgtk-3.so.0)
#4  0x00007f957c00eae0 g_hash_table_foreach (libglib-2.0.so.0)
#5  0x00007f957c929abc n/a (libgtk-3.so.0)
#6  0x00007f957c92080b n/a (libgtk-3.so.0)
#7  0x00007f957c972482 n/a (libgtk-3.so.0)
#8  0x00007f957c0dfb4a g_signal_emit_valist (libgobject-2.0.so.0)
#9  0x00007f957c0e07f0 g_signal_emit (libgobject-2.0.so.0)
#10 0x00007f957c92c924 gtk_cell_area_apply_attributes (libgtk-3.so.0)
#11 0x00007f957c6f8f3a gtk_tree_view_is_blank_at_pos (libgtk-3.so.0)
#12 0x000055dd1eba835f n/a (nemo)
#13 0x00007f957c974d37 n/a (libgtk-3.so.0)
#14 0x00007f957c0edd5a g_closure_invoke (libgobject-2.0.so.0)
#15 0x00007f957c0db88e n/a (libgobject-2.0.so.0)
#16 0x00007f957c0def1c g_signal_emit_valist (libgobject-2.0.so.0)
#17 0x00007f957c0e07f0 g_signal_emit (libgobject-2.0.so.0)
#18 0x00007f957c725c9a n/a (libgtk-3.so.0)
#19 0x00007f957c725fb4 n/a (libgtk-3.so.0)
#20 0x00007f957c829517 gtk_main_do_event (libgtk-3.so.0)
#21 0x00007f957c53b954 n/a (libgdk-3.so.0)
#22 0x00007f957c4e8904 n/a (libgdk-3.so.0)
#23 0x00007f957bfff3ee g_main_context_dispatch (libglib-2.0.so.0)
#24 0x00007f957c001201 n/a (libglib-2.0.so.0)
#25 0x00007f957c001241 g_main_context_iteration (libglib-2.0.so.0)
#26 0x00007f957c1b4a3e g_application_run (libgio-2.0.so.0)
#27 0x000055dd1eb74122 n/a (nemo)
#28 0x00007f957b734153 __libc_start_main (libc.so.6)
#29 0x000055dd1eb7416e n/a (nemo)

Stack trace of thread 32375:
#0  0x00007f957b8e3c45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f955fcdd24e n/a (librsvg-2.so.2)
#2  0x00007f955fcdd902 n/a (librsvg-2.so.2)
#3  0x00007f955fce2275 n/a (librsvg-2.so.2)
#4  0x00007f955fcdc647 n/a (librsvg-2.so.2)
#5  0x00007f955fe3ae0f n/a (librsvg-2.so.2)
#6  0x00007f955fe3b6ac n/a (librsvg-2.so.2)
#7  0x00007f957b8dd4cf start_thread (libpthread.so.0)
#8  0x00007f957b80c2d3 __clone (libc.so.6)

Stack trace of thread 32361:
#0  0x00007f957b8019ef __poll (libc.so.6)
#1  0x00007f957c001170 n/a (libglib-2.0.so.0)
#2  0x00007f957c001241 g_main_context_iteration (libglib-2.0.so.0)
#3  0x00007f957c001292 n/a (libglib-2.0.so.0)
#4  0x00007f957bfddc11 n/a (libglib-2.0.so.0)
#5  0x00007f957b8dd4cf start_thread (libpthread.so.0)
#6  0x00007f957b80c2d3 __clone (libc.so.6)

Stack trace of thread 32364:
#0  0x00007f957b8019ef __poll (libc.so.6)
#1  0x00007f957c001170 n/a (libglib-2.0.so.0)
#2  0x00007f957c001241 g_main_context_iteration (libglib-2.0.so.0)
#3  0x00007f95769eee5e n/a (libdconfsettings.so)
#4  0x00007f957bfddc11 n/a (libglib-2.0.so.0)
#5  0x00007f957b8dd4cf start_thread (libpthread.so.0)
#6  0x00007f957b80c2d3 __clone (libc.so.6)

Stack trace of thread 32362:
#0  0x00007f957b8019ef __poll (libc.so.6)
#1  0x00007f957c001170 n/a (libglib-2.0.so.0)
#2  0x00007f957c002113 g_main_loop_run (libglib-2.0.so.0)
#3  0x00007f957c171ba8 n/a (libgio-2.0.so.0)
#4  0x00007f957bfddc11 n/a (libglib-2.0.so.0)
#5  0x00007f957b8dd4cf start_thread (libpthread.so.0)
#6  0x00007f957b80c2d3 __clone (libc.so.6)

Stack trace of thread 32374:
#0  0x00007f957b8e3c45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f955fcdd24e n/a (librsvg-2.so.2)
#2  0x00007f955fcdd902 n/a (librsvg-2.so.2)
#3  0x00007f955fce2275 n/a (librsvg-2.so.2)
#4  0x00007f955fcdc647 n/a (librsvg-2.so.2)
#5  0x00007f955fe3ae0f n/a (librsvg-2.so.2)
#6  0x00007f955fe3b6ac n/a (librsvg-2.so.2)
#7  0x00007f957b8dd4cf start_thread (libpthread.so.0)
#8  0x00007f957b80c2d3 __clone (libc.so.6)

Stack trace of thread 32373:
#0  0x00007f957b8e3c45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f955fcdd24e n/a (librsvg-2.so.2)
#2  0x00007f955fcdd902 n/a (librsvg-2.so.2)
#3  0x00007f955fce2275 n/a (librsvg-2.so.2)
#4  0x00007f955fcdc647 n/a (librsvg-2.so.2)
#5  0x00007f955fe3ae0f n/a (librsvg-2.so.2)
#6  0x00007f955fe3b6ac n/a (librsvg-2.so.2)
#7  0x00007f957b8dd4cf start_thread (libpthread.so.0)
#8  0x00007f957b80c2d3 __clone (libc.so.6)

Stack trace of thread 32378:
#0  0x00007f957b8e3c45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f955fcdd24e n/a (librsvg-2.so.2)
#2  0x00007f955fcdd902 n/a (librsvg-2.so.2)
#3  0x00007f955fce2275 n/a (librsvg-2.so.2)
#4  0x00007f955fcdc647 n/a (librsvg-2.so.2)
#5  0x00007f955fe3ae0f n/a (librsvg-2.so.2)
#6  0x00007f955fe3b6ac n/a (librsvg-2.so.2)
#7  0x00007f957b8dd4cf start_thread (libpthread.so.0)
#8  0x00007f957b80c2d3 __clone (libc.so.6)

Stack trace of thread 32377:
#0  0x00007f957b8e3c45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f955fcdd24e n/a (librsvg-2.so.2)
#2  0x00007f955fcdd902 n/a (librsvg-2.so.2)
#3  0x00007f955fce2275 n/a (librsvg-2.so.2)
#4  0x00007f955fcdc647 n/a (librsvg-2.so.2)
#5  0x00007f955fe3ae0f n/a (librsvg-2.so.2)
#6  0x00007f955fe3b6ac n/a (librsvg-2.so.2)
#7  0x00007f957b8dd4cf start_thread (libpthread.so.0)
#8  0x00007f957b80c2d3 __clone (libc.so.6)

Stack trace of thread 32379:
#0  0x00007f957b8e3c45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f955fcdd24e n/a (librsvg-2.so.2)
#2  0x00007f955fcdd902 n/a (librsvg-2.so.2)
#3  0x00007f955fce2275 n/a (librsvg-2.so.2)
#4  0x00007f955fcdc647 n/a (librsvg-2.so.2)
#5  0x00007f955fe3ae0f n/a (librsvg-2.so.2)
#6  0x00007f955fe3b6ac n/a (librsvg-2.so.2)
#7  0x00007f957b8dd4cf start_thread (libpthread.so.0)
#8  0x00007f957b80c2d3 __clone (libc.so.6)

Stack trace of thread 560979:
#0  0x00007f957b806e9d syscall (libc.so.6)
#1  0x00007f957bfb211b g_cond_wait_until (libglib-2.0.so.0)
#2  0x00007f957c02ff43 n/a (libglib-2.0.so.0)
#3  0x00007f957c030134 g_async_queue_timeout_pop (libglib-2.0.so.0)
#4  0x00007f957bfd708a n/a (libglib-2.0.so.0)
#5  0x00007f957bfddc11 n/a (libglib-2.0.so.0)
#6  0x00007f957b8dd4cf start_thread (libpthread.so.0)
#7  0x00007f957b80c2d3 __clone (libc.so.6)

Stack trace of thread 32380:
#0  0x00007f957b8e3c45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f955fcdd24e n/a (librsvg-2.so.2)
#2  0x00007f955fcdd902 n/a (librsvg-2.so.2)
#3  0x00007f955fce2275 n/a (librsvg-2.so.2)
#4  0x00007f955fcdc647 n/a (librsvg-2.so.2)
#5  0x00007f955fe3ae0f n/a (librsvg-2.so.2)
#6  0x00007f955fe3b6ac n/a (librsvg-2.so.2)
#7  0x00007f957b8dd4cf start_thread (libpthread.so.0)
#8  0x00007f957b80c2d3 __clone (libc.so.6)

Stack trace of thread 32376:
#0  0x00007f957b8e3c45 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1  0x00007f955fcdd24e n/a (librsvg-2.so.2)
#2  0x00007f955fcdd902 n/a (librsvg-2.so.2)
#3  0x00007f955fce2275 n/a (librsvg-2.so.2)
#4  0x00007f955fcdc647 n/a (librsvg-2.so.2)
#5  0x00007f955fe3ae0f n/a (librsvg-2.so.2)
#6  0x00007f955fe3b6ac n/a (librsvg-2.so.2)
#7  0x00007f957b8dd4cf start_thread (libpthread.so.0)
#8  0x00007f957b80c2d3 __clone (libc.so.6)

-- Subject: Process 32358 (nemo) dumped core

Steps to reproduce

In the terminal of your choice:

1. cd /tmp
2. mkdir test
3. cd test
4. nemo . &
5. Make sure you're in nemo's "List View" by clicking the "List View" icon
6. mkdir test2
nemo's window should now look like this:
   
7. cd test2
8. touch test.txt
9. Switch to nemo's window and hit Ctrl+r to refresh the view and nemo should now place a disclosure triangle to the left of the test2 folder indicating there's a file inside of the folder:
   
10. rm test.txt
11. Switch to nemo and click the disclosure triangle. nemo will display string "(Empty)" below the test2 folder and immediately coredump.
    

[1]  + 578882 segmentation fault (core dumped)  nemo .

Expected behaviour
Please don't crash on empty folders. External programs can modify folder's contents without notifying nemo.

Other information
I'm not sure if other instances of "(Empty)" folders cause crashes but a source code search for that string might yield some other possible bugs.

[smurphos]

I can reproduce this both on 4.2.3 and 4.4.1 with the steps outlined by the OP.

Some additional info - terminal output from nemo 4.4.1 just before the crash.

(nemo:7851): Gtk-CRITICAL **: 06:11:15.036: ../../../../gtk/gtktreeview.c:6678 (validate_visible_area): assertion `has_child' failed.
There is a disparity between the internal view of the GtkTreeView,
and the GtkTreeModel.  This generally means that the model has changed
without letting the view know.  Any display from now on is likely to
be incorrect.


(nemo:7851): Gtk-CRITICAL **: 06:11:15.037: ../../../../gtk/gtktreeview.c:5558 (gtk_tree_view_bin_draw): assertion `has_child' failed.
There is a disparity between the internal view of the GtkTreeView,
and the GtkTreeModel.  This generally means that the model has changed
without letting the view know.  Any display from now on is likely to
be incorrect.


(nemo:7851): Gtk-CRITICAL **: 06:11:15.039: ../../../../gtk/gtktreeview.c:5558 (gtk_tree_view_bin_draw): assertion `has_child' failed.
There is a disparity between the internal view of the GtkTreeView,
and the GtkTreeModel.  This generally means that the model has changed
without letting the view know.  Any display from now on is likely to
be incorrect.


(nemo:7851): Gtk-CRITICAL **: 06:11:15.882: ../../../../gtk/gtktreeview.c:5558 (gtk_tree_view_bin_draw): assertion `has_child' failed.
There is a disparity between the internal view of the GtkTreeView,
and the GtkTreeModel.  This generally means that the model has changed
without letting the view know.  Any display from now on is likely to
be incorrect.


** (nemo:7851): CRITICAL **: 06:11:15.945: nemo_list_model_get_value: assertion 'model->details->stamp == iter->stamp' failed
sys:1: Warning: ../../../../gobject/gtype.c:4265: type id '0' is invalid
sys:1: Warning: can't peek value table for type '<invalid>' which is not currently referenced
...

[jmp1963]

Not sure why this (and many others) are closed. I'm still having this issue with Nemo 4.4.2 on Linux Mint 19.3.

Sorry - not qualified to add much more other than the crash is repeatable every time moving files results in an empty folder.

[nick-s-b]

@jmp1963 it's closed because this bug was definitely fixed. I cannot reproduce it anymore. Bug you're experiencing is something else and you'd need to track it down and try to replicate it.

[jmp1963]

@nick-s-b Thank's Nick,

Just checked again and although reproducible it isn't by the same steps/process as you listed (sorry there are so many of these!). It does however happen after moving all files and leaving the source folder empty. I'll investigate further and raise it as a different/new issue.

[avma]

Strange, this is closed (fixed) yet I'm having the exact same crash on Linux min 20 Cinnamon and Nemo 4.6.5.

`~ » killall nemo avi@avi-mint-pc
nemo: no process found

~ » nemo 1 ↵ avi@avi-mint-pc
Initializing nemo-image-converter extension
sys:1: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Start flacon 6.1.0 + git master a26d4884b1b6de8769f80c8a60837b26f88422da

(nemo:811940): Gtk-CRITICAL **: 11:22:36.648: ../../../../gtk/gtktreeview.c:6709 (validate_visible_area): assertion `has_child' failed.
There is a disparity between the internal view of the GtkTreeView,
and the GtkTreeModel. This generally means that the model has changed
without letting the view know. Any display from now on is likely to
be incorrect.

(nemo:811940): Gtk-CRITICAL **: 11:22:36.651: ../../../../gtk/gtktreeview.c:5587 (gtk_tree_view_bin_draw): assertion `has_child' failed.
There is a disparity between the internal view of the GtkTreeView,
and the GtkTreeModel. This generally means that the model has changed
without letting the view know. Any display from now on is likely to
be incorrect.

(nemo:811940): Gtk-CRITICAL **: 11:22:36.663: ../../../../gtk/gtktreeview.c:5587 (gtk_tree_view_bin_draw): assertion `has_child' failed.
There is a disparity between the internal view of the GtkTreeView,
and the GtkTreeModel. This generally means that the model has changed
without letting the view know. Any display from now on is likely to
be incorrect.

(nemo:811940): Gtk-CRITICAL **: 11:22:36.954: ../../../../gtk/gtktreeview.c:5587 (gtk_tree_view_bin_draw): assertion `has_child' failed.
There is a disparity between the internal view of the GtkTreeView,
and the GtkTreeModel. This generally means that the model has changed
without letting the view know. Any display from now on is likely to
be incorrect.

(nemo:811940): Gtk-CRITICAL **: 11:22:37.434: ../../../../gtk/gtktreeview.c:5587 (gtk_tree_view_bin_draw): assertion `has_child' failed.
There is a disparity between the internal view of the GtkTreeView,
and the GtkTreeModel. This generally means that the model has changed
without letting the view know. Any display from now on is likely to
be incorrect.

** (nemo:811940): CRITICAL **: 11:22:37.903: nemo_list_model_get_value: assertion 'model->details->stamp == iter->stamp' failed
sys:1: Warning: ../../../gobject/gtype.c:4268: type id '0' is invalid
sys:1: Warning: can't peek value table for type '' which is not currently referenced
[1] 811940 segmentation fault (core dumped) nemo

~ » nemo --version 139 ↵ avi@avi-mint-pc
nemo 4.6.5>`

[nick-s-b]

@avma I have experienced the same crash but it's less common now. I haven't been able to reproduce it reliably but it's definitely still crashing when a folder is empty.
In fact, when I see that (Empty) label below a folder, there's a 90% chance that nemo will crash.