double free when using --randomize with unloadable image file

[hidroto]

Setup

feh version 3.10.2-2-g2d8f9e1
compile time switches: verscmp xinerama
create two files
normal.png a normal loadable image file
empty.file an empty file

Run

feh --randomize normal.png empty.file

then move through the filelist with arrow keys.
feh wont always crash depending on the order of the filelist and perhaps other factors.
but when it does crash it reports

free(): double free detected in tcache 2
and the shell reports the process is terminated by signal SIGABRT.

may be the same bug as #535

[doughdemon]

Was able to reproduce.

The following seems to fix it.

diff --git a/src/slideshow.c b/src/slideshow.c
index 3944a68..c6c6901 100644
--- a/src/slideshow.c
+++ b/src/slideshow.c
@@ -227,6 +227,12 @@ void slideshow_change_image(winwidget winwid, int change, int render)
        /* The for loop prevents us looping infinitely */
        for (i = 0; i < our_filelist_len; i++) {
                winwidget_free_image(winwid);
+
+               if (last) {
+                       filelist = feh_file_remove_from_list(filelist, last);
+                       last = NULL;
+               }
+
 #ifdef HAVE_LIBEXIF
                /*
                 * An EXIF data chunk requires up to 50 kB of space. For large and
@@ -324,11 +330,6 @@ void slideshow_change_image(winwidget winwid, int change, int render)
                        break;
                }

-               if (last) {
-                       filelist = feh_file_remove_from_list(filelist, last);
-                       last = NULL;
-               }
-
                if (opt.on_last_slide == ON_LAST_SLIDE_HOLD && previous_file &&
                        ((current_file == filelist && change == SLIDE_NEXT) ||
                        (previous_file == filelist && change == SLIDE_PREV))) {

What causes the bug is I believe as follows:
At i=0, the for loop tries to go to the invalid empty.file. It fails and sets the last variable. Then, at i=1, since we are at the last image of the list, it is reordered, and the next file is randomly chosen. Only then, the logic to remove the invalid file from the list executes. Now, it may happen that the randomly chosen file is exactly the file to be removed from the list. Then, feh tries to remove the invalid file twice, and it crashes.

[doughdemon]

Applying pull request #414 is probably a better way to fix this.