LE8 on WeTeK OpenELEC: Freeze because of memory leak?

    Hi,

    last week I installed the new LibreELEC 8.0.0 release on one of my WeTeK OpenELEC boxes.

    To narrow things down and to be sure I wiped the complete box and the *only* plugin I installed is the "Tvheadend HTSP client 3.4.18.1".

    The Tvheadend server is *not* running on the box, but I'm streaming from a Tvheadend server on a RPi in the network.

    After several hours, it seems that Kodi is using up all the memory and the box either locks up or suffers from severe swapping with a load going up to 18 and above.

    To reproduce, one just has to boot up the box (using the default skin), start LiveTV and wait for some hours. No switching/GUI usage required to crash the system.

    Attached see two "top" screenshots - one with severe swapping and one with a died box - as well as a "journalctl -f" trace of a died box.

    I will add more logs if required/later.


    TIA,
    Sepp

    Hi,

    so I *tried* to make a more decent set of logs.

    Problem is, that when things finally go wrong, things a quite screwed up and one can't just use the samba logfile feature.

    So here is what I did:
    1) Rebooted
    2) Switched on LiveTV
    3) opened one SSH terminal with "journalctl -f"
    4) opened second SSH for "top" and later control
    5) waited for things to screw up
    6) when system was finally total stuck, I used the second terminal to kill kodi with "killall -9 kodi.bin". This took about 5 minutes just to accept the keystrokes.
    7) Tried to create the logfiles, but they were to big to be processed on the available "disk space"
    8) copied away "kodi.old.log" (nearly 1 GB!) and deleted it
    9) executed "createlog"
    10) found out, that in the created ZIP file also data from journalctl was lost.

    So here is what you get now:
    - a full logfile ZIP-ball created after things screwed up and KODI was manually killed, with "kodi.old.log" missing and crippled journalctl data
    - a separate zip-file with "kodi.old.log" -> ZIPPED 70 MB, TOO BIG TO UPLOAD
    - a separate zip-file with the trace of "journalctl -f" followed on a remote ssh terminal


    If you need more, please tell me.


    Sepp


    EDIT: Ok, I uploaded the big "kodi.old.log" to a one-click-hoster. Please find the file here:

    kodi.old.log.zip | Uloz.to

    Hello,

    did some more investigations and wrote a script to log the memory usage of the "kodi.bin" process.

    I did two runs now, and interesting enough, memory usage is always constant for a long time. But then, always after 400 minutes, memory usage starts to increase over some minutes until all memory is used up.

    Test procedure was: Reboot -> start monitoring script -> go to live TV -> watch first channel in fullscreen -> don't touch anymore

    Attached you find the results. One plot over the full time and one detailed plot for the "crawl up time" for each run.

    Any ideas?


    Cheers,
    Sepp

    I have the same issue with LibreELEC 8.0.0 on the Wetek Core. After a while the GUI is extremely slow and mosthly a SSH reboot is the only option.

    LibreELEC devs, I see several threads related to this topic, does it make sense to still share bug reports or is there enough information for you to investigate?

    chears

    Any news?

    On my side I did some more tests:

    First I installed the TVHeadend server add-on on the WeTek and changed the configuration of the TVHeadend client, so that I see the local TV stream and not the one of the remote server.
    Result: Same thing. Approx. 400 minutes everything works well, and then memory usage goes up until everything is too late.


    Then I installed the YouTube plugin and started a video 10 hours long (Cantina Band: Play that same song! :D ).
    Result: Kodi again freezes, but this time without memory usage increasing! The freeze also _seems_ to take place after approx. 400 minutes. Unfortunately, again all useful logs were lost due to the powercycle and/or the freeze. I will try to reproduce and somehow produce useful logs.

    Any ideas? Any advice?


    Cheers,
    Sepp

    codesnake: Good!

    As promised, I tried to produce useful logs. Doing so, I realized that the freeze always seems to occure around the overflow of dts_in/pts_in in CAMLCodec:: Decode. There is this 32 signed int value, and when it exceeds 0x7FFFFFFF things go wrong.


    Here the log for watching PVR with tvheadend client when the memory increase happens:

    And here with the YouTube plugin:

    I've also seen that the code in AMLCodec.cpp which should handle this overflow gracefully was changed between Jarvis and Krypton.

    Maybe it's here to search?