19:29:28.477 T:1941877760 DEBUG: LIRC: Update - NEW at 25460:160 0 KEY_OK devinput (KEY_OK)
19:29:28.477 T:1941877760 DEBUG: HandleKey: 11 (0x0b, obc244) pressed, action is OSD
19:29:28.478 T:1941877760 DEBUG: ------ Window Init (VideoOSD.xml) ------
(2018-01-26, 14:35)popcornmix Wrote:Hi Popcornmix,(2018-01-26, 02:43)Milhouse Wrote: To me this looks more like #0805 than #0804, but it's hard to say if #0806 is worse than #0805 - I'd probably say they're much the same, and that the problem starts with - or is made worse (a small leak becoming a much bigger leak) by - #0805.
The only major change in #0806 is the gcc/glibc bump but hopefully they're not involved, as that would be a major task to track down...and wouldn't really explain why this affects only HEVC playback and not any other video codec.
Does the leak seem to be once per play? i.e. if you play/stop after a few seconds repeatedly does memory exhaust much faster than playing a single file that lasts an hour? (I'd guess it probably would)
How hard would it be to build head of tree with older gcc/glibc? Does that crash with out-of-memory after repeated plays?
(I suspect that #0805 is really the culprit, but the evidence is currently a bit unclear).
BTW John is on holiday this week so we won't get an immediate fix, but would be nice to be sure the bug is in the hevc code when he returns.
(2018-01-26, 21:30)HiassofT Wrote: Build 0125d is fine, action is OSD again:
Code:19:29:28.477 T:1941877760 DEBUG: LIRC: Update - NEW at 25460:160 0 KEY_OK devinput (KEY_OK)
19:29:28.477 T:1941877760 DEBUG: HandleKey: 11 (0x0b, obc244) pressed, action is OSD
19:29:28.478 T:1941877760 DEBUG: ------ Window Init (VideoOSD.xml) ------
Thanks a lot for the testbuilds!
so long,
Hias
(2018-01-26, 21:35)ksooo Wrote: Could you please leave a comment in the affected PRs to give @xhaggi a headsup?
(2018-01-26, 21:31)bleep42 Wrote: Looks like Milhouse beat me to it, so for what it's worth, here are the results from #0806, I've only got top to give me the memory usage accurately.
bcmstat.sh is included as standard in my RPi/RPi2 builds. texturecache.py is also included too (including Generic). Just in case anyone finds them useful.bcmstat.sh -DAZ memory monitoring is more accurate than any other tool, but it does track GPU/RAM consumption for the whole system (and if pretty much all you're running is kodi then it makes life easier). If all you see are red allocations (and few if any green free's) then there's a good chance there's a leak.
gcc-6.2.0 and glibc-2.25 and the results initially look similar to #0804, with reduced leakage compared with #0805.
(2018-01-26, 23:32)popcornmix Wrote: Is LE currently using MALLOC_MMAP_THRESHOLD_=131072? (That is value kodi chose).Hmmm, interesting. I don't see this defined in kodi's environment:
xbmc:~ # tr '\0' '\n' < /proc/`pidof kodi.bin`/environ
HOSTNAME=xbmc
LD_LIBRARY_PATH=/usr/lib:/storage/.kodi/addons/script.common.plugin.cache/lib:/storage/.kodi/addons/script.module.certifi/lib:/storage/.kodi/addons/script.module.chardet/lib:/storage/.kodi/addons/script.module.idna/lib:/storage/.kodi/addons/script.module.parsedom/lib:/storage/.kodi/addons/script.module.requests/lib:/storage/.kodi/addons/script.module.routing/lib:/storage/.kodi/addons/script.module.simplejson/lib:/storage/.kodi/addons/script.module.urllib3/lib:/storage/.kodi/addons/virtual.system-tools/lib:/usr/lib/pulseaudio
SHLVL=1
HOME=/storage
PS1=\[\e[1;32m\]\h\[\e[1;32m\]:\[\e[1;34m\]\w \[\e[0m\]\$
SDL_MOUSE_RELATIVE=0
WAYLAND_DISPLAY=wayland-0
KODI_HOME=/usr/share/kodi/
JOURNAL_STREAM=8:12875
TERM=linux
KODI_ARGS=--lircdev /run/lirc/lircd
INVOCATION_ID=5e96265ed6a5477f8255e2e40cef8140
PATH=/usr/bin:/usr/sbin:/storage/.kodi/addons/service.hyperion/bin:/storage/.kodi/addons/virtual.system-tools/bin
DISPLAY=:0.0
SYSTEMD_COLORS=0
__GL_YIELD=USLEEP
KODI_TEMP=/storage/.kodi/temp
PWD=/
EDITOR=nano
(2018-01-26, 23:32)popcornmix Wrote: This is feeling a bit like the music database memory leak we had before in kodi (worked around with MALLOC_MMAP_THRESHOLD_).
It may not be an actual leak, but glibc's malloc heap can get fragmented with certain patterns of allocs/frees.
It feels a bit like the hevc update changed the sizes of some buffers that made things a little worse.
An updated glibc made things a lot worse.
Are you able to run with smaller settings of MALLOC_MMAP_THRESHOLD_ ?
Is LE currently using MALLOC_MMAP_THRESHOLD_=131072? (That is value kodi chose).
Can you try with, say, MALLOC_MMAP_THRESHOLD_=32768
d8440c9c3674682bfb010801b4122b7bd1b9189ce8c0288f062625258ce6bae1 (RPi)4ea7109cabaf813d5d1dda01c2cb1e87d196c06a42da7300bbcad03a5c279ea2 (RPi2)text:# uname -a
Linux rpi512 4.14.15 #1 Fri Jan 26 21:28:03 GMT 2018 armv6l GNU/Linux
# vcgencmd version
Jan 25 2018 18:14:16
Copyright © 2012 Broadcom
version 16ab01397c559d80e3239c4d9c453a999a9121b1 (clean) (release)
# lsb_release
LibreELEC (Milhouse): devel-20180126212647-#0126-g4ff4537 [Build #0126]
# Kodi version
(18.0-ALPHA1 Git:69a6725). Platform: Linux ARM 32-bit
MALLOC_MMAP_THRESHOLD_ (with #0126 on RPi3, gcc-7.2.0, glibc-2.26, gpu_mem=320MB, arm=704MB) and these are the results:
MALLOC_MMAP_THRESHOLD_.MALLOC_MMAP_THRESHOLD_ - a value of 8192 might be a usable value. I feel that going as low as 1024 might result in an excessive number of chunks for no real advantage. But that's all a bit finger-in-the-air.MALLOC_MMAP_THRESHOLD_=8192 for arm in future builds (commit).
