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 <anth...@derobert.net> 
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