Mailing List Archive

Are there Memory leaks in 0.28 Mythfrontend?
I'm seeing more and more that memory is creeping up on the frontend
process, is this a known issue?

I'm seeing this on 3 different frontends, the first one is a combined front
end

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4766 seven 20 0 7347912 1.440g 77840 S 1.3 14.8 453:09.80
mythfrontend.re

$ mythfrontend --version
xprop: unable to open display ''
Please attach all output as a file in bug reports.
MythTV Version : v0.28.1-19-g0037461
MythTV Branch : fixes/0.28
Network Protocol : 88
Library API : 0.28.20161120-1
QT Version : 5.2.1
Options compiled in:
linux profile use_hidesyms using_alsa using_oss using_pulse
using_pulseoutput using_backend using_bindings_perl using_bindings_python
using_bindings_php using_crystalhd using_dvb using_firewire using_frontend
using_hdhomerun using_vbox using_ceton using_hdpvr using_ivtv
using_joystick_menu using_libcec using_libcrypto using_libdns_sd
using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl
using_opengl_video using_opengl_themepainter using_qtwebkit using_qtscript
using_qtdbus using_sdl using_taglib using_v4l2 using_x11 using_xrandr
using_xv using_profiletype using_bindings_perl using_bindings_python
using_bindings_php using_freetype2 using_mythtranscode using_opengl
using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass
using_libxml2

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5163 seven 20 0 8116840 2.396g 77392 S 2.6 62.1 851:26.40
mythfrontend.re

$ mythfrontend --version
xprop: unable to open display ''
Please attach all output as a file in bug reports.
MythTV Version : v0.28.1-18-g7026623
MythTV Branch : fixes/0.28
Network Protocol : 88
Library API : 0.28.20161120-1
QT Version : 5.5.1
Options compiled in:
linux profile use_hidesyms using_alsa using_oss using_pulse
using_pulseoutput using_backend using_bindings_perl using_bindings_python
using_bindings_php using_crystalhd using_dvb using_firewire using_frontend
using_hdhomerun using_vbox using_ceton using_hdpvr using_ivtv
using_joystick_menu using_libcec using_libcrypto using_libdns_sd
using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl
using_opengl_video using_opengl_themepainter using_qtwebkit using_qtscript
using_qtdbus using_sdl using_taglib using_v4l2 using_x11 using_xrandr
using_xv using_profiletype using_bindings_perl using_bindings_python
using_bindings_php using_freetype2 using_mythtranscode using_opengl
using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass
using_libxml2

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13671 seven 20 0 5507908 962424 105772 S 0.7 47.0 389:35.67
mythfrontend.re

$ mythfrontend --version
xprop: unable to open display ''
Please attach all output as a file in bug reports.
MythTV Version : v0.28.1-8-ge9be5e0
MythTV Branch : fixes/0.28
Network Protocol : 88
Library API : 0.28.20161120-1
QT Version : 5.5.1
Options compiled in:
linux profile use_hidesyms using_alsa using_oss using_pulse
using_pulseoutput using_backend using_bindings_perl using_bindings_python
using_bindings_php using_crystalhd using_dvb using_firewire using_frontend
using_hdhomerun using_vbox using_ceton using_hdpvr using_ivtv
using_joystick_menu using_libcec using_libcrypto using_libdns_sd
using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl
using_opengl_video using_opengl_themepainter using_qtwebkit using_qtscript
using_qtdbus using_sdl using_taglib using_v4l2 using_x11 using_xrandr
using_xv using_profiletype using_bindings_perl using_bindings_python
using_bindings_php using_freetype2 using_mythtranscode using_opengl
using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass
using_libxml2

what troubleshooting do I need to provide to raise a bug? from previous
threads I think this required valgrind? but can someone confirm?

Cheers,

Anthony
Re: Are there Memory leaks in 0.28 Mythfrontend? [ In reply to ]
On Mon, Apr 17, 2017 at 11:14 PM, Anthony Giggins
<seven@seven.dorksville.net> wrote:
> I'm seeing more and more that memory is creeping up on the frontend process,
> is this a known issue?

I do not think it is known (otherwise it would be fixed),
but one should also be aware that due to caching, the
memory footprint of the frontend would be expected
to slowly increase (to some value) the longer it is
running, so what you are seeing may be "normal".

> what troubleshooting do I need to provide to raise a bug? from previous
> threads I think this required valgrind? but can someone confirm?

valgrind is your friend to detect true memory leaks
(as opposed to code not minimizing memory usage).
Using it, is not always.

To obtain useful results you may need to compile the
frontend with the debugging options (-g and -O0).
Typically, you want to use something like this:

valgrind --leak-check=full --error-limit=no --show-reachable=yes
--log-file=/tmp/valgrind.out /usr/local/bin/mythfrontend

Lastly, Qt itself may be the cause of any memory
leaks, and debugging Qt itself is far more challenging.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Are there Memory leaks in 0.28 Mythfrontend? [ In reply to ]
On 18 April 2017 5:10:14 pm Gary Buhrmaster <gary.buhrmaster@gmail.com> wrote:

> On Mon, Apr 17, 2017 at 11:14 PM, Anthony Giggins
> <seven@seven.dorksville.net> wrote:
>> I'm seeing more and more that memory is creeping up on the frontend process,
>> is this a known issue?
>
> I do not think it is known (otherwise it would be fixed),
> but one should also be aware that due to caching, the
> memory footprint of the frontend would be expected
> to slowly increase (to some value) the longer it is
> running, so what you are seeing may be "normal".
>
>> what troubleshooting do I need to provide to raise a bug? from previous
>> threads I think this required valgrind? but can someone confirm?
>
> valgrind is your friend to detect true memory leaks
> (as opposed to code not minimizing memory usage).
> Using it, is not always.
>
> To obtain useful results you may need to compile the
> frontend with the debugging options (-g and -O0).
> Typically, you want to use something like this:
>
> valgrind --leak-check=full --error-limit=no --show-reachable=yes
> --log-file=/tmp/valgrind.out /usr/local/bin/mythfrontend
>
> Lastly, Qt itself may be the cause of any memory
> leaks, and debugging Qt itself is far more challenging.
>

Another alternative if you are building using gcc is to use the built in
leak sanitizer.

./configure --extra-ldflags=-fsanitize=leak

But to make this work you first need to modify mythtv/settings.pro as shown
below (can someone push this up to github).


@@ -270,15 +270,17 @@ win32 {
# Globals in static libraries need special treatment on OS X
macx:QMAKE_CFLAGS_STATIC_LIB += -fno-common
-# figure out compile flags based on qmake info
+# figure out compile and link flags based on qmake info
# qmake 4.8.2 & 4.8.3 messes up OSX "-arch i386 -arch x86_64"
# clang 3.0 on Linux does not like duplicate arguments.
macx {
QMAKE_CFLAGS += $$CPPFLAGS $$CFLAGS
QMAKE_CXXFLAGS += $$CXXPPFLAGS $$ECXXFLAGS
+ QMAKE_LFLAGS += $$LDFLAGS
} else {
QMAKE_CFLAGS *= $$CPPFLAGS $$CFLAGS
QMAKE_CXXFLAGS *= $$CXXPPFLAGS $$ECXXFLAGS
+ QMAKE_LFLAGS *= $$LDFLAGS
}
profile:!win32:!macx:CONFIG += debug


This does not introduce any noticeable performance overhead. It prints a
leak analysis to stdout on exit.

Roger


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-dev
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org