Speicherverbrauch steigt mit der Zeit

  • wenn p Null wird, darfst Du s nicht vergessen.

    Das ist aber nur der Fehlerfall und erklärt jetzt nicht Euer herbes leak.

    Reelbox Avantgarde II, 2GB, Turion X2 (TL-66), Kingston SSD (64GB)
    BM2LTS 2.95.1 RC10

    Raspi 3, Libreelec 9.2.6

    QNAP TS 412

    DigibitR1

    Zyxel GS1900-24E

    Supermicro X11-SCL-IF, Xeon E2176, 32GB, 500GM SSD, 8TB HDD, Ubuntu 20.10, TVHeadend 4.3

  • Das ist aber nur der Fehlerfall und erklärt jetzt nicht Euer herbes leak

    Im Orignalcode von kls geht doch bei p!=s der Block, auf den p zeigt verloren und s zeigt ins Nirvana.

    Oder täusche ich mich da?

    Gruss
    SHF


  • ah, ich hab den Diff falsch verstanden: richtig, s wird freigegeben, p geht verloren der strcpy ist Quatsch weil von Realloc mit erledigt. Im Fehlerfall bleibt s erhalten aber hat eine unerwartete Größe.

    Reelbox Avantgarde II, 2GB, Turion X2 (TL-66), Kingston SSD (64GB)
    BM2LTS 2.95.1 RC10

    Raspi 3, Libreelec 9.2.6

    QNAP TS 412

    DigibitR1

    Zyxel GS1900-24E

    Supermicro X11-SCL-IF, Xeon E2176, 32GB, 500GM SSD, 8TB HDD, Ubuntu 20.10, TVHeadend 4.3

  • SHF du hast da vollkommen Recht, diese Funtion ist fehlerhaft!

    In erster Näherung sollte das wohl so aussehen:

    Allerdings habe ich eine Ausgabe eingebaut um zu sehen, ob diese Funktion überhaupt jemals aufgerufen wird.

    Bis jetzt kein Aufruf.

  • Hier die Funktion mit allen Checks:

    Bis jetzt immer noch kein Aufruf. Anscheinend wird die Funktion (zumindest im Core-VDR) nicht benutzt.

  • Anscheinend wird die Funktion (zumindest im Core-VDR) nicht benutzt.

    Hatte mich auch schon gewundert, warum der Fehler nicht auch anderweitig aufgefallen ist.

    An einigen Stellen (zB. args.c und sicher noch anderen) ist die Funktion aber schon drin.

    Gruss
    SHF


  • Wobei: cArgs::arg ist eine cStringList und kein cString ;-).

    Ups, das hatte mein "grep" dann fälschlicherweise mit erwischt. Mir war die Feinheit auf die Schnelle nicht aufgefallen .

    "Append" kommt ja nicht so selten vor ;-).


    Edit:

    cString::Append wird wohl wirklich nicht benutzt. Ich hab die Funktion auskommentiert und es gibt keine Fehlermeldungen.

    Gruss
    SHF


    The post was edited 1 time, last by SHF ().

  • Bei den Strings steht eine menge zeug drin. Einiges könnte vom skin sein...

    Ich denke der Dump ist vom Block:5645341c6000-56454ac39000 rw-p 00000000 00:00 0 [heap]?

    Der passt von der Grösse und es ist auch einzige, wo sich nennenswert was tut.


    So wie ich das sehe ist da der komplette EPG drin.

    Das Vorgehen hilft also auch nicht weiter.



    Ich empfehle nochmal, die Plugins auf das nötigste zu reduzieren und zu schauen, ob es dann immer noch auftritt.

    Den Skin-Plugin kann man jedenfalls ohne einschränkung Benutzbarkeit zum Test mal raus nehmen.

    Gruss
    SHF


  • Ich denke der Dump ist vom Block:5645341c6000-56454ac39000 rw-p 00000000 00:00 0 [heap]?

    Der passt von der Grösse und es ist auch einzige, wo sich nennenswert was tut.

    So wie ich das sehe ist da der komplette EPG drin.

    Ja der ist innerhalb von ein paar Minuten von 330 auf 370MB gewachsen.

    Das ganze EPG glaube ich kaum. Das wäre deutlich mehr.


    Da stehen auch Massenweise Strings drin wie 333333 oder auch Sachen die IBEV oder anderes Kryptisches.


    Der Speicheranstieg ist bei Bedienung (OSD) viel höher als wenn der VDR so füt Aufnahmen läuft.

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • 333333 ist z.b sehr oft vorhanden

    Code
    1. darkwing@darkwing-Lenovo-V110-15ISK ~/Schreibtisch $ grep -c ^333333 ./dump_out.strings
    2. 22824

    Ist das normal? Oder schon ein Hinweis auf ein Leck?

    MP-Logos (Kanallogos für VDR) - Picons2VDR (Kanallogos für VDR) - MV_Backup (Backup mit RSync) - Skin FlatPlus (Fork)

    „In zwei Jahren wird das Spam-Problem gelöst sein.“ [Bill Gates], Microsoft-Chef, 2004

  • Ja der ist innerhalb von ein paar Minuten von 330 auf 370MB gewachsen.

    Das ist nach den Start normal.

    Scheint am EPG zu liegen.

    Man muss eine Weile warten, bis sich das stabilisiert hat.

    Das ganze EPG glaube ich kaum. Das wäre deutlich mehr.

    Ob es wirklich vollständig ist, hab ich natürlich nicht kontrolliert, aber geschätzt 20% von dem Dump sind EPG.


    370MB kann man sich im Hexeditor nur Stichprobenhaft ansehen. Selbst durchblätter ist nicht in sinnvollem Zeitrahmen möglich!


    Da stehen auch Massenweise Strings drin wie 333333 oder auch Sachen die IBEV oder anderes Kryptisches.

    Das hat so ein Dump an sich ;-).

    333333 ist z.b sehr oft vorhanden

    Ist das normal? Oder schon ein Hinweis auf ein Leck?

    Kann ich nicht beurteilen, "333333" sagt mir nichts.

    Das kann default Wert in irgend einem Datenfeld sein oder sonstwas, was zufällig den String "333333" ergibt.


    Der Speicheranstieg ist bei Bedienung (OSD) viel höher als wenn der VDR so füt Aufnahmen läuft.

    Dann versuch es doch bitte mal ohne Skin-Plugins.

    Wenn dann der Speicheranstieg nicht mehr auftritt, weiss man, dass es an den Plugins liegt.

    Dann kannst du auch die Dumps vergleichen und sehen, ob die "333333" noch so häufig sind.


    Speicheranstieg ist bei Bedienung (Transponderwechsel) kann aber auch am EPG liegen. Das sollte sich aber nach einer Weile Zappen auf einem Niveau einpendeln.

    Gruss
    SHF