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
    1. dpkg-source: Fehler: Abbruch aufgrund unerwarteter Änderungen in den Originalquellen, siehe /tmp/vdr_2.4.1-1~etobi1.diff.wYhJqb
    2. 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

    The post was edited 1 time, last by 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! :)

    The post was edited 1 time, last by 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
    1. DATE TIME TZ YEAR PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    2. Fr 24. Dez 00:06:03 CET 2021 1546 vdr 20 0 2436296 117464 14400 S 35,3 1,5 157:22.41 vdr
    3. Sa 25. Dez 00:05:13 CET 2021 1546 vdr 20 0 2454704 139572 14424 S 23,5 1,8 493:51.31 vdr
    4. So 26. Dez 00:08:05 CET 2021 1546 vdr 20 0 2454704 139908 14424 S 17,6 1,8 808:08.03 vdr
    5. Mo 27. Dez 00:10:06 CET 2021 1546 vdr 20 0 2430116 142192 14056 S 23,5 1,9 1131:03 vdr
    6. 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
    1. DATE TIME TZ YEAR PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    2. Di 14. Dez 00:09:16 CET 2021 17130 vdr 20 0 2831532 741276 12964 S 22,2 9,7 1083:09 vdr
    3. Mi 15. Dez 00:05:27 CET 2021 17130 vdr 20 0 2813124 887308 12984 S 22,2 11,6 1420:43 vdr
    4. Do 16. Dez 00:05:37 CET 2021 17130 vdr 20 0 3224748 1,012g 12576 S 5,9 13,9 1748:13 vdr
    5. Fr 17. Dez 00:06:58 CET 2021 17130 vdr 20 0 3271888 1,182g 12676 S 33,3 16,2 2085:12 vdr
    6. Sa 18. Dez 00:09:29 CET 2021 17130 vdr 20 0 3292356 1,308g 12208 S 17,6 18,0 2427:13 vdr
    7. So 19. Dez 00:07:33 CET 2021 17130 vdr 20 0 3620036 1,461g 12208 S 23,5 20,1 2758:55 vdr
    8. Mo 20. Dez 00:09:23 CET 2021 17130 vdr 20 0 3604676 1,593g 12180 S 17,6 21,9 3109:44 vdr
    9. Di 21. Dez 00:05:23 CET 2021 17130 vdr 20 0 3886288 1,771g 8652 S 16,7 24,3 3466:51 vdr
    10. 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 !

    The post was edited 1 time, last by Marcus 2208: Vergleich zu vorher eingefügt ().

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

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

    gentoo (vdr-2.6.0 manuell installierg), Asus Sabertooth FX990, AMD FX8150, 16GB 1833, CineS2(kernel 5.15.x inkl. standard dvb Treiber), USB RC(inputevxd), Asus gt1030, vertex4 ssd (system), mdraid5 9TB