Package: minidlna
Version: 1.1.4+dfsg-4
Severity: important
Tags: upstream patch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I set minidlna to scan my FLAC files... and was surprised a short while
later to find the system unusable, thrashing to death. It was using over
10GiB of RAM.
I tracked it down to if a FLAC file (and maybe other formats that
support this) has multiple attached pictures, it malloc's memory to
store all the pictures—but leaks all of that memory, except for the last
picture.
That + high-res scans = goodbye system.
The attached patch fixes the memory leak, at least. Note that I added in
a log message for it... but possibly that should be removed. Or at least
changed to debug.
- -- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (130, 'unstable'), (120,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.0.1-btrfsfix+ (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages minidlna depends on:
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-59.2
ii libavformat56 10:2.6.3-dmo1
ii libavutil54 10:2.6.3-dmo1
ii libc6 2.19-18
ii libexif12 0.6.21-2
ii libflac8 1.3.1-2
ii libid3tag0 0.15.1b-11
ii libjpeg62-turbo 1:1.4.0-7
ii libogg0 1.3.2-1
ii libsqlite3-0 3.8.10.2-1
ii libvorbis0a 1.3.4-2
ii lsb-base 4.1+Debian13+nmu1
minidlna recommends no packages.
minidlna suggests no packages.
- -- Configuration Files:
/etc/minidlna.conf changed [not included]
- -- no debconf information
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlWWFYQACgkQ+z+IwlXqWf7oMQCggSzfrJ+/K5t+D5B6P39BAkju
g+gAnii6es7K4/sWUdyLugLPu8WqyIj8
=T7ri
-----END PGP SIGNATURE-----
commit 35f87ab930ea143861ca5c681030e8b658333ec5
Author: Anthony DeRobertis <anth...@derobert.net>
Date: Fri Jul 3 00:42:10 2015 -0400
Fix memory leak with multi-picture FLAC files.
On my music archive, minidlnad wasn't anywhere near through scanning,
and had already leaked in excess of 10GiB from this.
The basic problem is that song_metadata has one image pointer. When it
sees a picture metadata item, it mallocs some space and copies the
picture to that, then sets the image pointer. That's all well and good,
except FLAC (and some other formats, haven't checked them) allow more
than one picture. So on the second picture, it does the same
thing—except overwriting the previous pointer, thus leaking it.
Simple fix: check if != NULL, ignore picture.
diff --git a/debian/changelog b/debian/changelog
index 1508f61..a500137 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+minidlna (1.1.4+dfsg-4+asd1) UNRELEASED; urgency=medium
+
+ * Fix memory leak.
+
+ -- Anthony DeRobertis <anth...@derobert.net> Fri, 03 Jul 2015 00:21:05 -0400
+
minidlna (1.1.4+dfsg-4) unstable; urgency=medium
* Remove wrong 10-fix-FTBFS-on-Hurd.patch, it's senseless.
diff --git a/tagutils/tagutils-flc.c b/tagutils/tagutils-flc.c
index b8f41d4..11bb8be 100644
--- a/tagutils/tagutils-flc.c
+++ b/tagutils/tagutils-flc.c
@@ -75,6 +75,10 @@ _get_flctags(char *filename, struct song_metadata *psong)
break;
#if FLAC_API_VERSION_CURRENT >= 10
case FLAC__METADATA_TYPE_PICTURE:
+ if (psong->image) {
+ DPRINTF(E_INFO, L_SCANNER, "Ignoring additional image [%s]\n", filename);
+ break;
+ }
psong->image_size = block->data.picture.data_length;
if((psong->image = malloc(psong->image_size)))
memcpy(psong->image, block->data.picture.data, psong->image_size);
