Speicherleck im VDR oder einem Plugin

  • Ich habe mich jetzt mal dran gewagt. Die build-deb installiert und den Quellcode von eTobi geladen. Da es noch VDR 2.4.1 ist, habe ich nicht das diff von HelmutB angewendet, sondern habe die Stelle in nit.c editiert und die beiden delete d eingefügt. Soweit so gut. Wenn ich dann dpkg-buildpackage starte, kommt folgende Fehlermeldung:

    Code
    dpkg-source: Fehler: Abbruch aufgrund unerwarteter Änderungen in den Originalquellen, siehe /tmp/vdr_2.4.1-1~etobi1.diff.wYhJqb
    dpkg-buildpackage: Fehler: Fehler-Exitstatus von dpkg-source -b vdr-2.4.1 war 2

    So unerwartet finde ich die Änderungen jetzt nicht. Allerdings brauche ich wohl etwas Nachhilfe. Wäre das auch mit dem diff passiert? Was habe ich falsch gemacht? Laut der Fehlermeldung ist der Fehler dass ich dran rumgespielt habe. Aber das war ja schließlich das Ziel der Übung.

  • Bitte eigenes Thema aufmachen!

  • Bitte eigenes Thema aufmachen!

    Das IST mein Thema! :S

  • Ich habe die Quellen nochmal gelöscht und neu geholt. Dieses Mal habe ich nit.c mit dem diff von HelmutB gepatcht. Gleiche Fehlermeldung. Habe daraufhin ein dpkg-source --commit ausgeführt. Dann lief der build Prozess durch. Aber ehrlich gesagt weiß ich nicht wirklich was das --commit bewirkt. Werde nun versuchen, den neu gebauten VDR zu installieren. Das wird ein Spaß, ich höre jetzt schon meine Frau. ^^


    EDIT: Scheint zu laufen! :wow

    Einmal editiert, zuletzt von Marcus 2208 ()

  • Marcus 2208 vdr_rossi hat schon nicht unrecht, auch wenn das Dein Faden hier zur Lösung eines Speicherlecks ist. Das Umsetzen innerhalb Deiner Installation ist ein anderes Thema.


    Bei Debian Paketen bleibt das SRC tarball unangetastet und wird innerhalb das Build-/Packetierungsprozess gepatched und ergibt dadurch ein eigene Debian Source. Also SRC tarball plus zum Paket zugefügte Debian-Patches. Damit kann man schon Änderung recht elegant punktuell hinzufügen und auch wieder wegnehmen. Aber damit muss man sich etwas befassen und ist auch nicht in 2 Zeilen erklärt, daher wäre hierzu ein neuer Thread angebracht.

    HowTo: APT pinning

  • Okay, danke fnu! Habe beides verstanden. Ich war halt der Meinung, mein Start-Post würde beide Themen abdecken, habe ja extra auf mein produktives System und die Bedenken daran rumzudrehen hingewiesen. Aber ihr habt beide Recht, das macht es natürlich unübersichtlicher.


    Also back to ontopic please! :)

    Einmal editiert, zuletzt von Marcus 2208 ()

  • Also back to ontopic please! 🙂

    Sagte der Bock als Gärtner 🧐 , daher erinnere Dich bitte immer wieder daran.

    HowTo: APT pinning

  • Mein Kommentar war selbstironisch gemeint. Kam wohl nicht so rüber. Ich sagte ja bereits, dass ihr beide Recht habt.

  • Bei mir ist zumindest mit VDR 2.4.1 noch ein minimaler Anstieg im Speicher wahrnehmbar. Ich habe nur den Patch von HelmutB drin, der die beiden fehlenden delete d in nit.c hinzufügt.


    Code
    DATE       TIME     TZ  YEAR        PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    Fr 24. Dez 00:06:03 CET 2021       1546 vdr       20   0 2436296 117464  14400 S  35,3  1,5 157:22.41 vdr 
    Sa 25. Dez 00:05:13 CET 2021       1546 vdr       20   0 2454704 139572  14424 S  23,5  1,8 493:51.31 vdr 
    So 26. Dez 00:08:05 CET 2021       1546 vdr       20   0 2454704 139908  14424 S  17,6  1,8 808:08.03 vdr 
    Mo 27. Dez 00:10:06 CET 2021       1546 vdr       20   0 2430116 142192  14056 S  23,5  1,9   1131:03 vdr 
    Di 28. Dez 00:06:16 CET 2021       1546 vdr       20   0 2454704 143088  14112 S  17,6  1,9   1448:05 vdr

    Das ist aber nichts im Vergleich zu vorher:

    Code
    DATE       TIME     TZ  YEAR        PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    Di 14. Dez 00:09:16 CET 2021      17130 vdr       20   0 2831532 741276  12964 S  22,2  9,7   1083:09 vdr 
    Mi 15. Dez 00:05:27 CET 2021      17130 vdr       20   0 2813124 887308  12984 S  22,2 11,6   1420:43 vdr 
    Do 16. Dez 00:05:37 CET 2021      17130 vdr       20   0 3224748 1,012g  12576 S   5,9 13,9   1748:13 vdr 
    Fr 17. Dez 00:06:58 CET 2021      17130 vdr       20   0 3271888 1,182g  12676 S  33,3 16,2   2085:12 vdr 
    Sa 18. Dez 00:09:29 CET 2021      17130 vdr       20   0 3292356 1,308g  12208 S  17,6 18,0   2427:13 vdr 
    So 19. Dez 00:07:33 CET 2021      17130 vdr       20   0 3620036 1,461g  12208 S  23,5 20,1   2758:55 vdr 
    Mo 20. Dez 00:09:23 CET 2021      17130 vdr       20   0 3604676 1,593g  12180 S  17,6 21,9   3109:44 vdr 
    Di 21. Dez 00:05:23 CET 2021      17130 vdr       20   0 3886288 1,771g   8652 S  16,7 24,3   3466:51 vdr 
    Mi 22. Dez 00:08:34 CET 2021      17130 vdr       20   0 4039876 1,909g   8544 S  29,4 26,2   3813:35 vdr

    Man kann also sehr deutlich den Erfolg erkennen. Nochmals vielen Dank HelmutB !

    Einmal editiert, zuletzt von Marcus 2208 () aus folgendem Grund: Vergleich zu vorher eingefügt

  • Gestern hat der VDR sogar 20 MB abgespeckt! Ich mach mir langsam Sorgen, wird VDR magersüchtig? =O

    Code
    DATE       TIME     TZ  YEAR       PID USER       PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND 
    Fr 24. Dez 00:06:03 CET 2021       1546 vdr       20   0 2436296 117464  14400 S  35,3  1,5 157:22.41 vdr 
    Sa 25. Dez 00:05:13 CET 2021       1546 vdr       20   0 2454704 139572  14424 S  23,5  1,8 493:51.31 vdr 
    So 26. Dez 00:08:05 CET 2021       1546 vdr       20   0 2454704 139908  14424 S  17,6  1,8 808:08.03 vdr 
    Mo 27. Dez 00:10:06 CET 2021       1546 vdr       20   0 2430116 142192  14056 S  23,5  1,9   1131:03 vdr 
    Di 28. Dez 00:06:16 CET 2021       1546 vdr       20   0 2454704 143088  14112 S  17,6  1,9   1448:05 vdr 
    Mi 29. Dez 00:08:34 CET 2021       1546 vdr       20   0 2460884 123444  14144 S  33,3  1,6   1781:01 vdr
  • Hi,

    Nur um mal etwas OT zu gehen: betrifft es VDR 2.2.0 auch?

    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Kann man jetzt auch recht elegant mit GIT-Mitteln lösen. Klar geht das auf der Konsole, aber es geht auch mit Web-Tools:


    https://github.com/vdr-projects/vdr/blame/master/nit.c

    Bisschen scrollen an die richtige Stelle bringt einem zu dem Commit:

    https://github.com/vdr-project…ded040f2a3d17d4ebf7a0bf3f

    Und da liest man direkt das es Version 2.4.1 betrifft.


    Hier gezeigt anhand des GitHub-Mirrors. Ich konnte jetzt direkt auf dem offiziellen Repo im Webinterface kein "blame" finden.

  • kls aus irgendeinem Grund haben sich jetzt die Hashes der Commits verändert... Eigentlich sollte das nicht passieren. Wenn man vergleicht zwischen hier:


    http://git.tvdr.de/?p=vdr.git;…c95252193eff0401880dbb986


    und hier:


    https://github.com/vdr-project…ac2d20bb7665b37e9322bd879


    Gleiches Commit, anderer Hash. Aktuell bekomme ich die Mirrors also nicht abgeglichen es sei denn ich erzwinge das. Dürfte dann aber auch alle Tags vergurken...

  • kls erstes Commit das "wegläuft" ist das hier:


    http://git.tvdr.de/?p=vdr.git;…7a9c4020d3f85b0338c1ee6fb


    https://github.com/vdr-project…1fafb4d49d8100b0217c11d16


    Und jetzt sehe ich auch was da passiert ist. Ein Fehler in der HISTORY. Bisschen komisch wenn sich ein fertiges Commit nochmal ändert aber da die Änderung nicht zu tief in der Historie passiert ist, ist der "Schaden" überschaubar und ich könnte einfach ein "Forced-Push" machen. Allerdings warte ich erstmal noch auf Feedback von kls bevor ich dann später nochmal ran muss.

  • Sorry, ich hatte gesehen, dass ich mich bei den Datumsangaben vertan hatte und habe das "händisch" ausgebessert. Da ich das GIT immer komplett neu aus meinem RCS generiere, hat sich dadurch wohl was verändert. Sollte aber die einzige Stelle sein.

    Ich werde in Zukunft besser aufpassen...

  • Hallo, hätte einen Verbesserungsvorschlag:

    ich prüfe mittels valgrind auf Speicherlecks.

    bei den vdr threads läuft aber etwas schief (ausgabe unschön).
    falls innerhalb des threads ein malloc gemacht wird - gibt es einen fehler von valgrind.

    valgrind denkt wohl das der thread direkt nach dem start zerstört wurde.

    wenn man "pthread_detach(childTid)" nach cThread::StartThread(ans ende, vor return true;) verschiebt, dann klappt es besser.


    gruß, onur

  • wenn man "pthread_detach(childTid)" nach cThread::StartThread(ans ende) verschiebt, dann klappt es besser.

    Ich würde das gerne testen, aber wenn ich wörtlich Deiner Anweisung folge, kommt das hier heraus:

    Das ist natürlich offensichtlich Quatsch, weil der if-Zweig leer zurück bleibt, und "pthread_detach(childTid);" nie erreicht werden kann.


    Ich bin mir sicher, dass Du etwas anderes meintest und ich Deine Patch-Anweisung falsch verstanden habe.


    Noch was: wenn ich den vdr in valgrind starte und softhddevice attache, kommt ein Standbild, dann laufen die device buffer über und der vdr crasht. Das gleiche passiert bei libleak, außer dass das Bild ein paar mal ruckelt bis es crasht (ca. 5 Sekunden).

Jetzt mitmachen!

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