Speicherleck im VDR oder einem Plugin

  • Wenn der Thread dann aber abstürzt, werden seine Ressourcen nicht abgeräumt. Deshalb wird das ja im Thread-Kontext des startenden Threads aufgerufen.


    Bedeutet das also, dass valgrind mit detached threads nicht gut zurechtkommt?

  • 'childTid' ist zu diesem Zeitpunkt u.U. noch nicht gesetzt, daher wird der Thread wohl keine Resourcen freigeben.

    Ausserdem ist StartThread() 'static' und hat daher keinen Zugriff auf ein 'childTid'. Wenn, dann müsste es wohl 'Thread->childTid' heissen, aber das ist, wie gesagt, zu diesem Zeitpunkt womöglich noch nicht gesetzt.


    Ich muss gestehen, dass mir der Unterschied zwischen 'childTid' und 'childThreadId' jetzt auch nicht so ganz klar ist.

  • kls

    Thread->childTid habe ich korrigiert.


    damit childTid auch gültig ist sollte man nach einem erfolgreichem pthread_create() - auf den thread warten.

    z.B mit Funktion WaitForThreadStart und Variable bThreadStarted (bThreadStarted muss natürlich im konstruktor mit false initialisert werden)

  • So, wie ich die Diskussion zu valgrind und pthread im Internet verstehe, werden die Ressourcen der noch laufenden detached pthreads bei Programmende erst später freigegeben, als valgrind das wohl mag.


    Aber all zu tief bin ich da auch nicht drin.

  • @mini73
    ich habe folgendes beobachtet:
    valgrind bemerkt dass ein thread gestartet wird, und regsitriert malloc/new aus diesem thread.
    Wenn nun vor thread ende ein pthread_detach gemacht wird, denkt vargrind das der thread speichlecks hat.
    Wenn pthread_detach gemacht wird, bevor im thread ein malloc/new gemacht wird (zufall), dann meckert valgrind nicht.


    speicher-leck suche ist dadurch schwierig.

  • Solution 3 klingt eher wie eine Anleitung für Solution 1.

    Aber ja, gleich das detach beim create mitgeben, klingt nach einer guten Idee.

    Und da, wo jetzt das pthread_detach steht, könnte man dann das pthread_attr_destroy machen.

  • Hilft das hier?

  • kls

    Würdest du diese .gitignore Datei in dein Repository aufnehmen? Das würde sehr helfen. Natürlich ohne das .txt

    Code
    *.a
    *.o
    *.mo
    *.pot
    *.so
    .dependencies
    vdr
    vdr.pc
    include/
  • Ich wollt Erfolg melden! Zur Veranschaulichung hier einmal der Speicherverbrauch des VDR in tabellarischer Ausführung:



    Und hier noch der Speicherverbrauch des gesamten Systems grafisch:


    Man kann sehr schön sehen, dass der Sägezahn deutlich flacher geworden ist. Aber auch, dass der Speicherverbrauch vom VDR immernoch minimal wächst. In wie weit das normal ist, oder ob das noch andere Speicherlecks sind, weiß ich nicht. Ich werde das weiter beobachten, sowohl den Speicherverbrauch als auch diesen Thread hier.


    Grüße

    Marcus

  • pthread_attr_destroy kann man direkt nach thread create machen.

    if (attrp) pthread_attr_destroy(attrp);


    Solution 3 - signalisert valgrind das der thread detached läuft.
    ansonsten weiß das valgrind ja nicht sofort (valgrind meckert wenn zwischen pthread_create und pthread_detach ein malloc/new gemacht wird).


    ich habe das ganze so verstanden:

    pthread_detach bewirkt das nach thread ende, alle thread ressourcen freigegeben werden.


    vereinfachtes Beispiel:

    pthread_create = erstellt ein globales handle mit nummer 1 (unser childTid).

    wenn der thread beendet wird exisitert dieses handle weiter, damit childTid vom aufrufenden thread weiter gültig bleibt.


    pthread_detach (egal woher es aufgerufen wird) bewirkt:

    alle thread ressourcen (childTid) bitte nach thread ende freigeben.

    die variable childTid ist ab diesem zeitpunkt unsicher.

    es könnte sogar passieren das inzwischen ein anderes pthread_create die selbe id vergeben hat.


    im vdr code wird das durch die variable Thread->threadrunning = false geprüft.

    hier könnte man zusätzlich ein Thread->childTid=0 machen (falls man pthread_detach in den thread verschiebt - Solution 2).

  • Ich hab das pthread_attr_destroy zwei mal drin, weil es im Fehlerfall einen early-return gibt. Wenn das nur im if-Zweig aufgerufen würde, wäre es eine Lücke.

    Wobei ich nicht weiß, ob das überhaupt nötig ist.


    Wenn man bei pthread_create keine Attribute angibt, muss man entweder pthread_detach oder pthread_join aufrufen. Das kann man ja durch das Attribut wunderbar umgehen (wobei man dann pthread_attr_destroy stattdessen aufrufen muss - muss man oder sollte man? Die Manpage finde ich da nicht so ganz eindeutig).


    Ich würde die Lösung mit den Attributen bevorzugen - es ist eindeutiger.

    Und man ist nicht auf irgend einen Aufruf irgendwo an anderer Stelle angewiesen, der dann vielleicht auch nicht ausgeführt wird, falls im Thread eine Exception auftritt.

  • ich habe alle varianten durchgetestet - damit es schnell geht - mit einem TestThread.

    verlässlich ist keine der varianten - alles ziemlich sinnlos.

    am verlässlichsten funktioniert valgrind, wenn man in cThread::StartThread vor dem Aufruf von Action, ein sleep mit 200ms macht.

    dann meckert valgrind nicht mehr.

  • "verlässlich" und "sleep" in einem Satz... 😂


    Dann muss man solche Fehlmeldungen wohl einfach ignorieren. 200ms sind schon eine Menge Zeit und verändern ggf. auch das Verhalten des vdr, falls man das nur für Speicherlecks mal einbaut. Das scheint mir also auch keine Lösung zu sein.


  • für alle jene die eine specherleck suchen, und die valgrind ausgabe etwas verringern wollen, die müssen den vdr mit so einem sleep bauen.
    aber auch 200ms ist nicht verlässlich, leider ist das ganze stark cpu (anzahl und auslastung) abhängig.
    echt frustrierend.

    zumindest liefert valgrind (auch ohne patches) nach dem beenden das richtige ergebnis.
    die ausgabe zur laufzeit ist falsch.

    LEAK SUMMARY:

    ==29891== definitely lost: 0 bytes in 0 blocks

    ==29891== indirectly lost: 0 bytes in 0 blocks

    ==29891== possibly lost: 0 bytes in 0 blocks

  • Das ist jetzt schon der zweite schwerwiegende Fehler im epg-search Plugin. Nur deswegen hatte ich meinen Ubuntu LTS Server geupdated und mir damit eine Tonne weiterer Probleme eingehandelt. Sehr sehr ärgerlich. Ich entwickle selbst seit 30 Jahren professionell Software in C++ und habe für solche Bugs kein Verständnis. Wenn man nicht weiß, was man tut - und es dann auch nicht testet - lässt man es besser.


    Frage: Kommt der Bugfix in die offiziellen Repositories?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!