Bug#909682: Bug #909682: Memory leak with gst_tag_list_add_id3_image
So, as promised, I've been playing that album again, and it's again leaking memory. I tried a few things to get it to free the memory. Putting tracks from a different album in the middle didn't do it. Neither did deleting the rest of the album from the playlist and playing something else (in fact, it continued to leak — just <1MB at a time, presumably due to the new album having a single smaller picture). Maybe it's also really noticeable because there are 29 large pictures attached to each track. I got a better backtrack from gdb: Thread 23 "task116" hit Breakpoint 1, 0x7f89dd9fe320 in gst_tag_list_add_id3_image () from /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0 (gdb) bt #0 0x7f89dd9fe320 in gst_tag_list_add_id3_image () at /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0 #1 0x7f8998013b00 in gst_flac_parse_handle_picture (buffer=0x7f88d814bce0, flacparse=0x7f891e1c3690 [GstFlacParse]) at /usr/include/gstreamer-1.0/gst/base/gstbytereader.h:651 #2 0x7f8998013b00 in gst_flac_parse_handle_block_type (sbuffer=0x7f88d814bce0, type=6, flacparse=0x7f891e1c3690 [GstFlacParse]) at gstflacparse.c:1520 #3 0x7f8998013b00 in gst_flac_parse_parse_frame (frame=0x7f89250505e0, frame=0x7f89250505e0, size=301495, parse=0x7f891e1c3690 [GstFlacParse]) at gstflacparse.c:1574 #4 0x7f8998013b00 in gst_flac_parse_handle_frame (parse=0x7f891e1c3690 [GstFlacParse], frame=0x7f89250505e0, skipsize=) at gstflacparse.c:870 #5 0x7f89dcce46b2 in gst_base_parse_handle_buffer (parse=parse@entry=0x7f891e1c3690 [GstFlacParse], buffer=, skip=skip@entry=0x7f895fffe75c, flushed=flushed@entry=0x7f895fffe758) at gstbaseparse.c:2160 #6 0x7f89dcce4d8f in gst_base_parse_scan_frame (parse=parse@entry=0x7f891e1c3690 [GstFlacParse], klass=) at gstbaseparse.c:3464 #7 0x7f89dcce8302 in gst_base_parse_loop (pad=) at gstbaseparse.c:3543 #8 0x7f89dcc30f41 in gst_task_func (task=0x7f897c237050 [GstTask]) at gsttask.c:332 #9 0x7f89dcdb0ad3 in g_thread_pool_thread_proxy (data=) at ../../../../glib/gthreadpool.c:307 #10 0x7f89dcdb0135 in g_thread_proxy (data=0x7f8924ffb0f0) at ../../../../glib/gthread.c:784 #11 0x7f89dd154f2a in start_thread (arg=0x7f895700) at pthread_create.c:463 #12 0x7f89db094edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) c Continuing. Looks like its some threaded workpool... I later added a breakpoint on pthread_create to try and see where the thread is coming from, and it looks like the threads are creating more threads and maybe never exiting? This appears to happen every track (the task number goes up by two each time; I didn't add the breakpoint on pthread_create in time to catch 116 creating 118, probably. Here is 118 creating 120, which then goes on to cal gst_tag_list_add_id3_image): Thread 26 "task118" hit Breakpoint 2, __pthread_create_2_1 (newthread=newthread@entry=0x7f89004337a0, attr=attr@entry=0x7f89717f5610, start_routine=start_routine@entry=0x7f89dcdb00e0 , arg=arg@entry=0x7f8900433770) at pthread_create.c:610 610 in pthread_create.c (gdb) bt #0 0x7f89dd155210 in __pthread_create_2_1 (newthread=newthread@entry=0x7f89004337a0, attr=attr@entry=0x7f89717f5610, start_routine=start_routine@entry=0x7f89dcdb00e0 , arg=arg@entry=0x7f8900433770) at pthread_create.c:610 #1 0x7f89dcdce2e0 in g_system_thread_new (thread_func=thread_func@entry=0x7f89dcdb00e0 , stack_size=stack_size@entry=0, error=error@entry=0x7f89717f56e0) at ../../../../glib/gthread-posix.c:1177 #2 0x7f89dcdb043f in g_thread_new_internal (name=0x7f89dcde27c2 "pool", proxy=0x7f89dcdb00e0 , func=0x7f89dcdb0a60 , data=0x7f89b0050780, stack_size=0, error=0x7f89717f56e0) at ../../../../glib/gthread.c:874 #3 0x7f89dcdb07ad in g_thread_pool_start_thread (pool=pool@entry=0x7f89b0050780, error=error@entry=0x7f89717f56e0) at ../../../../glib/gthreadpool.c:407 #4 0x7f89dcdb0da3 in g_thread_pool_start_thread (error=0x7f89717f56e0, pool=0x7f89b0050780) at ../../../../glib/gthreadpool.c:552 #5 0x7f89dcdb0da3 in g_thread_pool_push (pool=0x7f89b0050780, data=data@entry=0x7f8959f45f20, error=error@entry=0x7f89717f5750) at ../../../../glib/gthreadpool.c:563 #6 0x7f89dcc31f6a in default_push (pool=0x7f89b0043920 [GstTaskPool], func=0x7f89dcc30dc0 , user_data=, error=0x7f89717f5750) at gsttaskpool.c:106 #7 0x7f89dcc31b26 in start_task (task=0x7f88e1746710 [GstTask]) at gsttask.c:652 #8 0x7f89dcc31b26 in gst_task_set_state (task=task@entry=0x7f88e1746710 [GstTask], state=state@entry=GST_TASK_STARTED) at gsttask.c:704 #9 0x7f89dcc061bb in gst_pad_start_task (pad=0x7f890f81ac90 [GstPad], func=0x7f897056cd80 , user_data=0x7f890f81ac90, notify=0x0) at gstpad.c:6169 #10 0x7f89dcc003e6 in gst_pad_set_active (pad=pad@entry=0x7f890f81ac90 [GstPad], active=1) at gstpad.c:1107 #11 0x7f89dcbde0ad in activate_pads (vpad=, ret=0x7f89717f58a0, active=0x7f89717f58fc) at
Bug#909682: Bug #909682: Memory leak with gst_tag_list_add_id3_image
It went away at some point after that and I haven't seen it since... but you all are right, it might be file-specific. I plopped "lastplayed:>62d lastplayed:<64d" into the filter box, which should get to what I was playing around the time of that bug report, and it appears it was https://musicbrainz.org/release/db77f67d-9e9b-4623-8ea1-baab173cbe49 — which is weird, because that file shouldn't be any different than most of the others in my collection: it was ripped from CD to FLAC with morituri, replaygain added with metaflac, cover art scanned & uploaded to Cover Art Archive then put in the files w/ tags via Picard. It is a long album (19 discs total, FLAC files are 11GB total). Maybe that's it. Anyway, in the next few days I'll try playing that album again and see what happens. On 11/7/18 8:50 PM, Bernhard Übelacker wrote: Dear Maintainer, hello Anthony DeRobertis, I just tried to reproduce this issue in a buster amd64 qemu VM with a uptodate buster at 2018-09-27. On Wed, 26 Sep 2018 13:42:01 -0400 Anthony DeRobertis wrote: Package: clementine Version: 1.3.1+git565-gd20c2244a+dfsg-1 Severity: normal I'm not sure if this is a Clementine bug or a Gstreamer bug, but I've noticed that when I leave Clementine running for a bit, its memory usage grows massive (many GiB). I'm playing almost exlusively FLAC files, which all have (fairly large) embedded artwork, multiple images per file. I used heaptrack to attempt to track down where the memory leak is. This is after only a day or two of use: MEMORY LEAKS 857.27MB leaked over 2418654 calls from g_malloc in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 826.58MB leaked over 1941 calls from: g_slice_alloc in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 0x7fe9ca6e49d0 in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 gst_buffer_new_allocate in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 gst_tag_image_data_to_image_sample in /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0 gst_tag_list_add_id3_image in /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0 0x7fe994f1ca1f in /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstaudioparsers.so 0x7fe9ca8116b1 in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 0x7fe9ca811d8e in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 0x7fe9ca815301 in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 0x7fe9ca75df40 in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 0x7fe9ca8ddad2 in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 0x7fe9ca8dd134 in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 start_thread in /lib/x86_64-linux-gnu/libpthread.so.0 __clone in /lib/x86_64-linux-gnu/libc.so.6 I could just get a backtrace with debug symbols that looks very similar to Anthonys call stack from heaptrack: (gdb) bt #0 0x75de3640 in g_malloc (n_bytes=n_bytes@entry=4079355) at ../../../../glib/gmem.c:95 #1 0x75dfb5b3 in g_slice_alloc (mem_size=mem_size@entry=4079355) at ../../../../glib/gslice.c:1024 #2 0x75c0d9d1 in _sysmem_new_block (flags=(unknown: 0), maxsize=4079211, align=7, offset=0, size=4079204) at gstallocator.c:417 #3 0x75c190c2 in gst_buffer_new_allocate (allocator=allocator@entry=0x0, size=size@entry=4079204, params=params@entry=0x0) at gstbuffer.c:839 #4 0x76c61412 in gst_tag_image_data_to_image_sample (image_data=0x7fff600380d1 "\377\330\377", , image_data_len=4079203, image_type=GST_TAG_IMAGE_TYPE_BACK_COVER) at tags.c:528 #5 0x76c513b3 in gst_tag_list_add_id3_image (tag_list=0x7fff60003140, image_data=, image_data_len=image_data_len@entry=4079203, id3_picture_type=) at gstid3tag.c:379 #6 0x7fffa0065b00 in gst_flac_parse_handle_picture (buffer=0x7fff5c02f6d0, flacparse=0x7fff5c049af0 [GstFlacParse]) at /usr/include/gstreamer-1.0/gst/base/gstbytereader.h:651 #7 0x7fffa0065b00 in gst_flac_parse_handle_block_type (sbuffer=0x7fff5c02f6d0, type=6, flacparse=0x7fff5c049af0 [GstFlacParse]) at gstflacparse.c:1520 #8 0x7fffa0065b00 in gst_flac_parse_parse_frame (frame=0x7fff600030f0, frame=0x7fff600030f0, size=4079268, parse=0x7fff5c049af0 [GstFlacParse]) at gstflacparse.c:1574 #9 0x7fffa0065b00 in gst_flac_parse_handle_frame (parse=0x7fff5c049af0 [GstFlacParse], frame=0x7fff600030f0, skipsize=) at gstflacparse.c:870 #10 0x75d3a6b2 in gst_base_parse_handle_buffer (parse=parse@entry=0x7fff5c049af0 [GstFlacParse], buffer=, skip=skip@entry=0x7fff737e075c, flushed=flushed@entry=0x7fff737e0758) at gstbaseparse.c:2160 #11 0x75d3ad8f in gst_base_parse_scan_frame (parse=parse@entry=0x7fff5c049af0 [GstFlacParse], klass=) at gstbaseparse.c:3464 #12 0x75d3e302 in gst_base_parse_loop (pad=) at gstbaseparse.c:3543 #13 0x75c86f41 in gst_task_func (task=0x7fff78042830 [GstTask]) at gsttask.c:332 #14 0x75e06ad3 in g_thread_pool_thread_proxy (data=) at ../../.
Bug#909682: Bug #909682: Memory leak with gst_tag_list_add_id3_image
Now really with the mentioned file.
# snapshot
deb [check-valid-until=no]
http://192.168.178.25:/debian-10-buster-snapshot.debian.org/ buster main
deb-src [check-valid-until=no]
http://192.168.178.25:/debian-10-buster-snapshot.debian.org/ buster main
deb [check-valid-until=no]
http://192.168.178.25:/debian-10-buster-debug-snapshot.debian.org/
buster-debug main
debian-10-buster-snapshot.debian.org
https://snapshot.debian.org/archive/debian/20180927T00Z/
debian-10-buster-debug-snapshot.debian.org
https://snapshot.debian.org/archive/debian-debug/20180927T00Z/
apt update
apt dist-upgrade
reboot
apt-show-versions | grep No | awk '{print $1}' | xargs dpkg --purge
apt autoremove
apt install devscripts dpkg-dev xserver-xorg lightdm xterm openbox heaptrack
heaptrack-gui valgrind htop mc clementine clementine-dbgsym libglib2.0-0-dbgsym
libgstreamer1.0-0-dbg gstreamer1.0-plugins-base-dbg
gstreamer1.0-plugins-good-dbg libgstreamer1.0-dev
systemctl start lightdm
mkdir gstreamer1.0/orig -p
cdgstreamer1.0/orig
apt source gstreamer1.0
cd ../..
mkdir gst-plugins-base1.0/orig -p
cdgst-plugins-base1.0/orig
apt source gst-plugins-base1.0
cd ../..
mkdir gst-plugins-good1.0/orig -p
cdgst-plugins-good1.0/orig
apt source gst-plugins-good1.0
cd ../..
ffmpeg -f lavfi -i "sine=frequency=1000:duration=5" test.wav
ffmpeg -i test.wav output-file.flac
# Adding via Easytag /usr/share/digikam/about/images/body-background.jpg to
output-file.flac, change picture type.
for i in {1..30}; do cp output-file.flac output-file-$i.flac; done
$ mediainfo sshfs/home/benutzer/output-file.flac
General
Complete name: sshfs/home/benutzer/output-file.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size: 19.5 MiB
Duration : 5 s 0 ms
Overall bit rate mode: Variable
Overall bit rate : 32.7 Mb/s
Cover: Yes / Yes / Yes / Yes
Cover description: body-background.jpg /
body-background.jpg / body-background.jpg / body-background.jpg
Cover type : Cover (back) / Publisher logo /
Leaflet page
Cover MIME : image/jpeg / image/jpeg / image/jpeg
/ image/jpeg
Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 5 s 0 ms
Bit rate mode: Variable
Bit rate : 99.8 kb/s
Channel(s) : 1 channel
Channel layout : C
Sampling rate: 44.1 kHz
Bit depth: 16 bits
Compression mode : Lossless
Stream size : 60.9 KiB (0%)
Writing library : Lavf58.12.100
export DISPLAY=:0
heaptrack /usr/bin/clementine
heaptrack --analyze "/home/benutzer/heaptrack.clementine.10299.gz"
heaptrack --analyze "/home/benutzer/heaptrack.clementine.10299.gz" | grep
gst_tag_image_data_to_image_sample -B7 -A23
valgrind --leak-check=full --log-file=valgrind_$(date +%Y-%m-%d_%H-%M-%S).log
/usr/bin/clementine
# no allocation appears of the size of the image ...
benutzer@debian:~$ heaptrack /usr/bin/clementine
heaptrack output will be written to
"/home/benutzer/heaptrack.clementine.23781.gz"
starting application, this might take some time...
__logging_message__01:10:37.833 WARN unknown libpng
warning: iCCP: known incorrect sRGB profile
libGL error: pci id for fd 51: 1234:, driver (null)
libGL error: No driver found
libGL error: failed to load driver: (null)
01:11:01.420 ERROR logging:57 Source ID 11 was not found
when attempting to remove it
__logging_message__01:11:05.076 WARN unknown
QObject::killTimer: Timers cannot be stopped from another thread
__logging_message__01:11:05.077 WARN unknown
QObject::~QObject: Timers cannot be stopped from another thread
heaptrack stats:
allocations:979074
leaked allocations: 23740
temporary allocations: 154858
Heaptrack finished! Now run the following to investigate the data:
heaptrack --analyze "/home/benutzer/heaptrack.clementine.23781.gz"
benutzer@debian:~$ heaptrack --analyze
"/home/benutzer/heaptrack.clementine.23781.gz" | grep
gst_tag_image_data_to_image_sample -B8 -A22
in /lib/x86_64-linux-gnu/libc.so.6
8.16MB consumed over 8 calls from:
g_slice_alloc
in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
0x7fddf446a9d0
in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
gst_buffer_new_allocate
Bug#909682: Bug #909682: Memory leak with gst_tag_list_add_id3_image
Dear Maintainer, hello Anthony DeRobertis, I just tried to reproduce this issue in a buster amd64 qemu VM with a uptodate buster at 2018-09-27. On Wed, 26 Sep 2018 13:42:01 -0400 Anthony DeRobertis wrote: > Package: clementine > Version: 1.3.1+git565-gd20c2244a+dfsg-1 > Severity: normal > > I'm not sure if this is a Clementine bug or a Gstreamer bug, but I've > noticed that when I leave Clementine running for a bit, its memory usage > grows massive (many GiB). I'm playing almost exlusively FLAC files, > which all have (fairly large) embedded artwork, multiple images per > file. > > I used heaptrack to attempt to track down where the memory leak is. This > is after only a day or two of use: > > MEMORY LEAKS > 857.27MB leaked over 2418654 calls from > g_malloc > in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 > 826.58MB leaked over 1941 calls from: > g_slice_alloc > in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 > 0x7fe9ca6e49d0 > in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 > gst_buffer_new_allocate > in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 > gst_tag_image_data_to_image_sample > in /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0 > gst_tag_list_add_id3_image > in /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0 > 0x7fe994f1ca1f > in /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstaudioparsers.so > 0x7fe9ca8116b1 > in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 > 0x7fe9ca811d8e > in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 > 0x7fe9ca815301 > in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 > 0x7fe9ca75df40 > in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 > 0x7fe9ca8ddad2 > in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 > 0x7fe9ca8dd134 > in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 > start_thread > in /lib/x86_64-linux-gnu/libpthread.so.0 > __clone > in /lib/x86_64-linux-gnu/libc.so.6 I could just get a backtrace with debug symbols that looks very similar to Anthonys call stack from heaptrack: (gdb) bt #0 0x75de3640 in g_malloc (n_bytes=n_bytes@entry=4079355) at ../../../../glib/gmem.c:95 #1 0x75dfb5b3 in g_slice_alloc (mem_size=mem_size@entry=4079355) at ../../../../glib/gslice.c:1024 #2 0x75c0d9d1 in _sysmem_new_block (flags=(unknown: 0), maxsize=4079211, align=7, offset=0, size=4079204) at gstallocator.c:417 #3 0x75c190c2 in gst_buffer_new_allocate (allocator=allocator@entry=0x0, size=size@entry=4079204, params=params@entry=0x0) at gstbuffer.c:839 #4 0x76c61412 in gst_tag_image_data_to_image_sample (image_data=0x7fff600380d1 "\377\330\377", , image_data_len=4079203, image_type=GST_TAG_IMAGE_TYPE_BACK_COVER) at tags.c:528 #5 0x76c513b3 in gst_tag_list_add_id3_image (tag_list=0x7fff60003140, image_data=, image_data_len=image_data_len@entry=4079203, id3_picture_type=) at gstid3tag.c:379 #6 0x7fffa0065b00 in gst_flac_parse_handle_picture (buffer=0x7fff5c02f6d0, flacparse=0x7fff5c049af0 [GstFlacParse]) at /usr/include/gstreamer-1.0/gst/base/gstbytereader.h:651 #7 0x7fffa0065b00 in gst_flac_parse_handle_block_type (sbuffer=0x7fff5c02f6d0, type=6, flacparse=0x7fff5c049af0 [GstFlacParse]) at gstflacparse.c:1520 #8 0x7fffa0065b00 in gst_flac_parse_parse_frame (frame=0x7fff600030f0, frame=0x7fff600030f0, size=4079268, parse=0x7fff5c049af0 [GstFlacParse]) at gstflacparse.c:1574 #9 0x7fffa0065b00 in gst_flac_parse_handle_frame (parse=0x7fff5c049af0 [GstFlacParse], frame=0x7fff600030f0, skipsize=) at gstflacparse.c:870 #10 0x75d3a6b2 in gst_base_parse_handle_buffer (parse=parse@entry=0x7fff5c049af0 [GstFlacParse], buffer=, skip=skip@entry=0x7fff737e075c, flushed=flushed@entry=0x7fff737e0758) at gstbaseparse.c:2160 #11 0x75d3ad8f in gst_base_parse_scan_frame (parse=parse@entry=0x7fff5c049af0 [GstFlacParse], klass=) at gstbaseparse.c:3464 #12 0x75d3e302 in gst_base_parse_loop (pad=) at gstbaseparse.c:3543 #13 0x75c86f41 in gst_task_func (task=0x7fff78042830 [GstTask]) at gsttask.c:332 #14 0x75e06ad3 in g_thread_pool_thread_proxy (data=) at ../../../../glib/gthreadpool.c:307 #15 0x75e06135 in g_thread_proxy (data=0x7fff5c045b70) at ../../../../glib/gthread.c:784 #16 0x761aaf2a in start_thread (arg=0x7fff737e1700) at pthread_create.c:463 #17 0x73f09edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (For some reason heaptracks locations 3 last digits are one lower than gdbs?) Unfortunately I never received a heaptrack report that shows this allocation as leaked on my test system. Was this a different heaptrack version or I just used it wrong? Also a valgrind run did not show a leak at this location. > I have no idea why that backtrace doesn't show any Clementine code in > it. I tried installing some more -dbg/-dbgsym packages, but maybe I had > to do it before starting Clementin
Bug#909682: Memory leak with gst_tag_list_add_id3_image
Package: clementine Version: 1.3.1+git565-gd20c2244a+dfsg-1 Severity: normal I'm not sure if this is a Clementine bug or a Gstreamer bug, but I've noticed that when I leave Clementine running for a bit, its memory usage grows massive (many GiB). I'm playing almost exlusively FLAC files, which all have (fairly large) embedded artwork, multiple images per file. I used heaptrack to attempt to track down where the memory leak is. This is after only a day or two of use: MEMORY LEAKS 857.27MB leaked over 2418654 calls from g_malloc in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 826.58MB leaked over 1941 calls from: g_slice_alloc in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 0x7fe9ca6e49d0 in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 gst_buffer_new_allocate in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 gst_tag_image_data_to_image_sample in /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0 gst_tag_list_add_id3_image in /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0 0x7fe994f1ca1f in /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstaudioparsers.so 0x7fe9ca8116b1 in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 0x7fe9ca811d8e in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 0x7fe9ca815301 in /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 0x7fe9ca75df40 in /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 0x7fe9ca8ddad2 in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 0x7fe9ca8dd134 in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 start_thread in /lib/x86_64-linux-gnu/libpthread.so.0 __clone in /lib/x86_64-linux-gnu/libc.so.6 I have no idea why that backtrace doesn't show any Clementine code in it. I tried installing some more -dbg/-dbgsym packages, but maybe I had to do it before starting Clementine. Note this is the main clementine process, not the tagreader processes: $ ps u | sed -e '1p;/[c]lementine/!d' USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND anthony 15944 0.5 6.6 4407604 1650488 pts/4 Sl+ Sep24 16:30 clementine anthony 15956 0.0 0.1 276992 37368 pts/4Sl+ Sep24 0:20 /usr/bin/clementine-tagreader /tmp/clementine_-631367825 anthony 15958 0.0 0.1 276992 39392 pts/4Sl+ Sep24 0:20 /usr/bin/clementine-tagreader /tmp/clementine_-792921086 anthony 15959 0.0 0.1 276992 37676 pts/4Sl+ Sep24 0:20 /usr/bin/clementine-tagreader /tmp/clementine_-1767394138 anthony 15963 0.0 0.1 276988 37340 pts/4Sl+ Sep24 0:20 /usr/bin/clementine-tagreader /tmp/clementine_-1468073315 anthony 15967 0.0 0.1 276988 37492 pts/4Sl+ Sep24 0:20 /usr/bin/clementine-tagreader /tmp/clementine_-1581559023 anthony 15968 0.0 0.1 276992 37624 pts/4Sl+ Sep24 0:20 /usr/bin/clementine-tagreader /tmp/clementine_-1038521661 anthony 15969 0.0 0.1 276992 39180 pts/4Sl+ Sep24 0:20 /usr/bin/clementine-tagreader /tmp/clementine_-1682697807 anthony 15970 0.0 0.1 276992 37908 pts/4Sl+ Sep24 0:20 /usr/bin/clementine-tagreader /tmp/clementine_-391160903 -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (200, 'unstable'), (150, 'stable'), (100, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages clementine depends on: ii gstreamer1.0-plugins-base 1.14.3-2 ii gstreamer1.0-plugins-good 1.14.3-1 ii gstreamer1.0-plugins-ugly 1.14.3-1 ii libc6 2.27-6 ii libcdio18 1:2.0.0-dmo2 ii libchromaprint1 1.4.3-2+b1 ii libcrypto++65.6.4-8 ii libfftw3-double33.3.8-2 ii libgcc1 1:8.2.0-7 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6 ii libglib2.0-02.58.1-2 ii libgpod40.8.3-13 ii libgstreamer-plugins-base1.0-0 1.14.3-2 ii libgstreamer1.0-0 1.14.3-1 ii libimobiledevice6 1.2.1~git20180302.3a37a4e-1 ii liblastfm5-11.0.9-1 ii libmtp9 1.1.13-1 ii libmygpo-qt5-1 1.1.0-2 ii libplist3 2.0.0-5 ii libprojectm2v5 2.1.0+dfsg-4+b3 ii libprotobuf10 3.0.0-9.1 ii libpulse0 12.2-2 ii libqt5concurrent5 5.11.1+dfsg-8 ii libqt5core5a5.11.1+dfsg-8 ii libqt5dbus5 5.11.1+dfsg-8 ii libqt5gui5 5.11.1+dfsg-8 ii libqt5network5 5.11.1+dfsg-8 ii libqt5opengl5 5.11.1+df
