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-baab173cbe49which 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 <[email protected]> 
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  0x00007ffff5de3640 in g_malloc (n_bytes=n_bytes@entry=4079355) at 
../../../../glib/gmem.c:95
#1  0x00007ffff5dfb5b3 in g_slice_alloc (mem_size=mem_size@entry=4079355) at 
../../../../glib/gslice.c:1024
#2  0x00007ffff5c0d9d1 in _sysmem_new_block (flags=(unknown: 0), 
maxsize=4079211, align=7, offset=0, size=4079204) at gstallocator.c:417
#3  0x00007ffff5c190c2 in gst_buffer_new_allocate 
(allocator=allocator@entry=0x0, size=size@entry=4079204, 
params=params@entry=0x0) at gstbuffer.c:839
#4  0x00007ffff6c61412 in gst_tag_image_data_to_image_sample (image_data=0x7fff600380d1 
"\377\330\377", <incomplete sequence \340>, image_data_len=4079203, 
image_type=GST_TAG_IMAGE_TYPE_BACK_COVER) at tags.c:528
#5  0x00007ffff6c513b3 in gst_tag_list_add_id3_image (tag_list=0x7fff60003140, 
image_data=<optimized out>, image_data_len=image_data_len@entry=4079203, 
id3_picture_type=<optimized out>) at gstid3tag.c:379
#6  0x00007fffa0065b00 in gst_flac_parse_handle_picture (buffer=0x7fff5c02f6d0, 
flacparse=0x7fff5c049af0 [GstFlacParse]) at 
/usr/include/gstreamer-1.0/gst/base/gstbytereader.h:651
#7  0x00007fffa0065b00 in gst_flac_parse_handle_block_type 
(sbuffer=0x7fff5c02f6d0, type=6, flacparse=0x7fff5c049af0 [GstFlacParse]) at 
gstflacparse.c:1520
#8  0x00007fffa0065b00 in gst_flac_parse_parse_frame (frame=0x7fff600030f0, 
frame=0x7fff600030f0, size=4079268, parse=0x7fff5c049af0 [GstFlacParse]) at 
gstflacparse.c:1574
#9  0x00007fffa0065b00 in gst_flac_parse_handle_frame (parse=0x7fff5c049af0 
[GstFlacParse], frame=0x7fff600030f0, skipsize=<optimized out>) at 
gstflacparse.c:870
#10 0x00007ffff5d3a6b2 in gst_base_parse_handle_buffer 
(parse=parse@entry=0x7fff5c049af0 [GstFlacParse], buffer=<optimized out>, 
skip=skip@entry=0x7fff737e075c, flushed=flushed@entry=0x7fff737e0758) at 
gstbaseparse.c:2160
#11 0x00007ffff5d3ad8f in gst_base_parse_scan_frame (parse=parse@entry=0x7fff5c049af0 
[GstFlacParse], klass=<optimized out>) at gstbaseparse.c:3464
#12 0x00007ffff5d3e302 in gst_base_parse_loop (pad=<optimized out>) at 
gstbaseparse.c:3543
#13 0x00007ffff5c86f41 in gst_task_func (task=0x7fff78042830 [GstTask]) at 
gsttask.c:332
#14 0x00007ffff5e06ad3 in g_thread_pool_thread_proxy (data=<optimized out>) at 
../../../../glib/gthreadpool.c:307
#15 0x00007ffff5e06135 in g_thread_proxy (data=0x7fff5c045b70) at 
../../../../glib/gthread.c:784
#16 0x00007ffff61aaf2a in start_thread (arg=0x7fff737e1700) at 
pthread_create.c:463
#17 0x00007ffff3f09edf 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 Clementine.
Heaptrack may be not prepared to use the debug information
delivered by the dbg packages. I also got no stacks from heaptrack
files record while dbgsym packages were installed.

Note this is the main clementine process, not the tagreader processes:

$ ps u | sed -e '1p;/[c]lementine/!d'
USER       PID %CPU %MEM    VSZ   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/4    Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-631367825
anthony  15958  0.0  0.1 276992 39392 pts/4    Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-792921086
anthony  15959  0.0  0.1 276992 37676 pts/4    Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-1767394138
anthony  15963  0.0  0.1 276988 37340 pts/4    Sl+  Sep24   0:20 
/usr/bin/clementine-tagreader /tmp/clementine_-1468073315
While playing I could not see an increase of memory usage percentage in htop.


Following is the location where the memory allocated in given
stack was freed in my test system:

(gdb) bt
#0  0x00007ffff5de3720 in g_free (mem=0x7fff6041bf50) at 
../../../../glib/gmem.c:193
#1  0x00007ffff5c4bb88 in _gst_memory_free (mem=0x7fff6041bf50) at 
gstmemory.c:97
#2  0x00007ffff5c1794a in gst_memory_unref (memory=<optimized out>) at 
../gst/gstmemory.h:345
#3  0x00007ffff5c1794a in _gst_buffer_free (buffer=0x7fff5c02fd30) at 
gstbuffer.c:749
#4  0x00007ffff5c76713 in gst_buffer_unref (buf=<optimized out>) at 
../gst/gstbuffer.h:442
#5  0x00007ffff5c76713 in _gst_sample_free (sample=0x7fffd41290f0) at 
gstsample.c:82
#6  0x00007ffff5ee45e0 in g_value_unset (value=value@entry=0x7fff6c005b18) at 
../../../../gobject/gvalue.c:275
#7  0x00007ffff5c79cdc in gst_structure_free (structure=0x7fffd41091a0) at 
gststructure.c:385
#8  0x00007ffff5c8149d in __gst_tag_list_free (list=0x7fffd411f9e0) at 
gsttaglist.c:720
#9  0x00007ffff5ee45e0 in g_value_unset (value=value@entry=0x7fff6c0042b8) at 
../../../../gobject/gvalue.c:275
#10 0x00007ffff5c79cdc in gst_structure_free (structure=0x7fffd4120580) at 
gststructure.c:385
#11 0x00007ffff5c4746d in _gst_message_free (message=0x7fff78043590) at 
gstmessage.c:218
#12 0x00007ffff5dd9e5d in g_list_foreach (list=<optimized out>, 
list@entry=0x555556f4d340 = {...}, func=0x7ffff5c1eb60 <gst_message_unref>, 
user_data=user_data@entry=0x0) at ../../../../glib/glist.c:1013
#13 0x00007ffff5dd9e8b in g_list_free_full (list=0x555556f4d340 = {...}, 
free_func=<optimized out>) at ../../../../glib/glist.c:223
#14 0x00007ffff5c1fdaf in gst_bus_set_flushing (bus=<optimized out>, 
flushing=<optimized out>) at gstbus.c:478
#15 0x00007ffff5c5f3e5 in gst_pipeline_change_state (element=0x5555576de090 
[GstPipeline], transition=<optimized out>) at gstpipeline.c:549
#16 0x00007ffff5c38eee in gst_element_change_state 
(element=element@entry=0x5555576de090 [GstPipeline], 
transition=GST_STATE_CHANGE_READY_TO_NULL) at gstelement.c:2952
#17 0x00007ffff5c398ee in gst_element_continue_state 
(element=element@entry=0x5555576de090 [GstPipeline], 
ret=ret@entry=GST_STATE_CHANGE_SUCCESS) at gstelement.c:2660
#18 0x00007ffff5c390d5 in gst_element_change_state 
(element=element@entry=0x5555576de090 [GstPipeline], transition=<optimized 
out>) at gstelement.c:2991
#19 0x00007ffff5c398ee in gst_element_continue_state 
(element=element@entry=0x5555576de090 [GstPipeline], 
ret=ret@entry=GST_STATE_CHANGE_SUCCESS) at gstelement.c:2660
#20 0x00007ffff5c390d5 in gst_element_change_state 
(element=element@entry=0x5555576de090 [GstPipeline], 
transition=transition@entry=GST_STATE_CHANGE_PLAYING_TO_PAUSED) at 
gstelement.c:2991
#21 0x00007ffff5c3960e in gst_element_set_state_func (element=0x5555576de090 
[GstPipeline], state=GST_STATE_NULL) at gstelement.c:2906
#22 0x00005555558d3cd2 in GstEnginePipeline::~GstEnginePipeline() 
(this=0x555557178d30, __in_chrg=<optimized out>) at 
./src/engines/gstenginepipeline.cpp:506
#23 0x00005555558d3e09 in GstEnginePipeline::~GstEnginePipeline() 
(this=0x555557178d30, __in_chrg=<optimized out>) at 
./src/engines/gstenginepipeline.cpp:501
#24 0x00005555558c6792 in 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() 
(this=0x5555573e0550) at /usr/include/c++/8/ext/atomicity.h:69
#25 0x00005555558c6792 in 
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (this=<optimized 
out>, __in_chrg=<optimized out>) at /usr/include/c++/8/bits/shared_ptr_base.h:706
#26 0x00005555558c6792 in std::__shared_ptr<GstEnginePipeline, 
(__gnu_cxx::_Lock_policy)2>::~__shared_ptr() (this=<optimized out>, 
__in_chrg=<optimized out>) at /usr/include/c++/8/bits/shared_ptr_base.h:1145
#27 0x00005555558c6792 in std::__shared_ptr<GstEnginePipeline, 
(__gnu_cxx::_Lock_policy)2>::reset() (this=0x55555680d778) at 
/usr/include/c++/8/bits/shared_ptr_base.h:1263
#28 0x00005555558c6792 in GstEngine::EndOfStreamReached(int, bool) (this=0x55555680d6c0, 
pipeline_id=<optimized out>, has_next_track=<optimized out>) at 
./src/engines/gstengine.cpp:753
#29 0x0000555555ae8262 in GstEngine::qt_static_metacall(QObject*, QMetaObject::Call, int, 
void**) (_o=0x55555680d6c0, _c=<optimized out>, _id=<optimized out>, 
_a=0x7fff64003ec0) at ./obj-x86_64-linux-gnu/src/engines/moc_gstengine.cpp:211
#30 0x00007ffff721a072 in QObject::event(QEvent*) () at 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#31 0x00007ffff4c864a1 in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#32 0x00007ffff4c8dae0 in QApplication::notify(QObject*, QEvent*) () at 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#33 0x00007ffff71f0579 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#34 0x00007ffff71f356b in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#35 0x00007ffff7242c03 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#36 0x00007ffff5dddc3e in g_main_dispatch (context=0x55555677a3e0) at 
../../../../glib/gmain.c:3182
#37 0x00007ffff5dddc3e in g_main_context_dispatch 
(context=context@entry=0x55555677a3e0) at ../../../../glib/gmain.c:3847
#38 0x00007ffff5ddded8 in g_main_context_iterate 
(context=context@entry=0x55555677a3e0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=<optimized out>) at 
../../../../glib/gmain.c:3920
#39 0x00007ffff5dddf6c in g_main_context_iteration (context=0x55555677a3e0, 
may_block=1) at ../../../../glib/gmain.c:3981
#40 0x00007ffff7242223 in 
QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () 
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#41 0x00007fffe56d1e51 in  () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#42 0x00007ffff71ef24b in 
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#43 0x00007ffff71f73c2 in QCoreApplication::exec() () at 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#44 0x0000555555851d93 in main (argc=<optimized out>, argv=<optimized out>) at 
./src/main.cpp:462
#45 0x00007ffff3e34b17 in __libc_start_main (main=0x555555851500 <main>, argc=1, 
argv=0x7fffffffe608, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized 
out>, stack_end=0x7fffffffe5f8) at ../csu/libc-start.c:310
#46 0x0000555555854e1a in _start () at ./src/main.cpp:478


Attached a file with some details on my debugging and the input file used,
maybe that has a special content.
Possibly you can track it down to a single file and provide the
output of mediainfo of that file.

Kind regards,
Bernhard

Reply via email to