free accompanying EXIF data when freeing an image

This fixes two memory bugs that only manifest with exif=1 and long-running
slideshows.

* when feh loads an image, it writes exif data to file->ed. Previously, this
  data was never free'd, causing a memory leak on subsequent loads of the same
  file.
* As file->ed is never free'd, the accumulated EXIF data consumes a significant
  amount of memory over time. with slideshow-delay = 10 and two days of
  runtime, feh may exceed 1 GB of memory usage. If the slideshow is so large
  that feh does not encounter the same image twice in this time, this is not
  detected as a memory leak, as each EXIF data chunk is referenced from the
  filelist.

See <https://github.com/derf/feh/issues/553> for details.

Closes #553

1 files changed, 12 insertions, 0 deletions

diff --git a/src/slideshow.c b/src/slideshow.c
index 07a1e94..2eb10da 100644
--- a/src/slideshow.c
+++ b/src/slideshow.c
@@ -225,6 +225,18 @@ 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);
+#ifdef HAVE_LIBEXIF
+		/*
+		 * An EXIF data chunk requires up to 50 kB of space. For large and
+		 * long-running slideshows, this would acculumate gigabytes of
+		 * EXIF data after a few days. We therefore do not cache EXIF data
+		 * in slideshows.
+		 */
+		if (FEH_FILE(winwid->file->data)->ed) {
+			exif_data_unref(FEH_FILE(winwid->file->data)->ed);
+			FEH_FILE(winwid->file->data)->ed = NULL;
+		}
+#endif
 		switch (change) {
 		case SLIDE_NEXT:
 			current_file = feh_list_jump(filelist, current_file, FORWARD, 1);