Posts by SHF

    Wenn man einfach mit make LCLBLD=1 baut wird versucht die Plugins nach /usr/local/lib/vdr zu installieren.

    Besonders unschön ist das wenn man als root arbeitet, da man dann nicht mal eine Fehlermeldung erhält. In dem Fall hat man u.U. Chaos im System angerichtet, ohne wirklich zu merken, was passiert ist.


    Natürlich ist INSTALL korrekt beschieben, dass man den Parameter LCLBLD=1 setzen und Make.config.template nach Make.config kopieren muss.

    Da ich ausser setzen von LCLBLD=1 nichts ändere, bin ich zum wiederholten male in die o.g. Falle getappt.


    Ursache ist, dass ohne Make.config die Verzeichnisse für make LCLBLD=1 nur teilweise stimmen.

    Die Fehlenden sind in der Makefile recht einfach zu ergänzen:

    Jetzt hat man auch mit make LCLBLD=1 das Verhalten der "alten" Makefile, ohne sonst irgendwas ändern zu müssen.


    Es funktioniert sowohl mit Plugins mit neuer als auch "alter" Makefile. Getestet mit VDR 2.4.1.

    Soweit ich es mir angesehen habe, sollten die Defaults, so wie ich sie eingefügt habe, auch mit nichts kollidieren.

    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.

    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.

    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.

    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.

    Mit cppcheck habe ich auch schon das eine oder andere gefunden und es gibt noch mehr tools.

    Das tool hatte ich sogar schon installiert.

    Ich denke ich hatte es installiert, weil ich es auf den VDR los lassen wollte, hab es dann aber wohl vergessen.

    Inzwischen ist das nachgeholt und es hat auch prompt was gefunden:

    Code
    1. [ci.c:2885]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
    2. [libsi/si.c:58]: (error) Invalid number of character '(' when no macros are defined.
    3. [tools.c:1108]: (error) Memory leak: p

    Bei den ersten beiden Treffern bin ich mir nicht sicher, ob das wirklich Fehler sind.


    Beim Dritten müsste aber was dran sein.

    Ich denke, der "strcpy" macht da keinen Sinn:

    Wobei das so bei einem Rückgabewert von "NULL" noch immer zu Fehlern führt.




    Dann hab ich den VDR doch noch zum Laufen gebracht. (Irgendwie ist da Durcheinander mir den Headers passiert.)

    Ich hatte den dann jetzt auch ein paar Stunden mit libleak laufen gelassen. Nach ein paar Meldungen ganz am Anfang kam dann aber gar nichts mehr.

    Ohne DVB-Input und mit Dummydevice scheint das Speicherleck also nicht aufzutreten.

    Doch, es läuft bei mir unter Gentoo x64 und vdr-2.4.1 ohne Probleme. Die Quelle kommt von hier: vdr-dummydevice-2.0.0.

    Von da hab ich es auch.

    Ohne dummydevice geht es aber auch nicht, da beendet der VDR wegen fehlendem Ausgabedevice.

    Mehr als die o.g. Fehlermeldung kommt auch nicht. Leider sagt mir die gar nichts.


    - Ein Leak, weil ein Pointer "vergessen" wird, ohne ihn freizugeben.

    - Eine Datenstruktur, die immer mehr Daten sammelt und größer wird, [...]
    Kandidaten für den zweiten Fall sind Listen usw. der Events, Schedules, Recordings, Channels...

    Den ersten Fall müsste libleak doch abdecken?

    Zumindest wenn malloc() ... für die Speicherbereiche verwendet wird.


    Bei Events, Schedules ... hatte ich schon überlegt einen Zähler einzubauen, der die Elemente mit zählt.


    e-fence

    Stimmt, das hauch schon mal gehört.

    Erstmal muss ich den VDR hier aber überhaupt mal zum laufen bringen.



    Den kompletten VDR mit Plugins neu bauen lassen und analysieren?

    Ich würde es erst mal auf das Plugin eingrenzen.

    Als erstes mal nur mit den nötigen Plugins zur Ein und Ausgabe versuchen. Dann nach und nach die Anderen.


    Wenn du das Plugin hast, wirst du die Lösung wahrscheinlich auch bald haben.

    Bei skindesigner und softhddevice gab es immer mal wieder Probleme mit einigen Versionen der verwendeten Bibliotheken (ffmpeg zB.). Ich schätze, dass es da hängen wird.

    Das noepg-plugin wäre auch noch eine Möglichkeit.

    Aktuell hab ich aber eh keine DVB-Karte in diesem Rechner.


    Als erstes wollte ich den VDR überhaupt mal mit dem dummydevice-plugin zum laufen bringen.

    Aktuell scheitert es mit der Fehlermeldung:

    vdr: malloc.c:3760: _int_malloc: Assertion `(unsigned long) (size) >= (unsigned long) (nb)' failed.

    Make lief problemlos durch.

    Kann es sein dass das dummydevice-plugin nicht mehr mit vdr 2.4.1 läuft?

    Ich gehe mal davon aus, dass einfach Sat-Kabel abziehen keine Lösung wäre weil der VDR dann in "Emergency-Exit" geht?

    AFAIK macht der VDR das nur, wenn eine Aufnahme läuft.

    Wegen möglicher Nebenwirkungen des Sat-Kabel abziehens bin ich aber auch nicht sicher.

    Was den Speicherverbrauch erhöht ist ja allgemein noch im dunklen. Ich habe z.B. ein System ganz ohne Ausgabe.

    Ohne Ausgabe tritt es auf, das scheint sicher.

    Die Frage ist, ob es auch ohne DVB-Input passiert.


    Das EPG produziert halt extremes Rauschen, da wäre es hilfreich, das los zu sein.

    So, ich hab doch mal schnell einen Blick drauf geworfen.


    Wenn ich das richtig interpretiere, werden von den [ anon ] markierten Blöcken werden einige grösser.

    Wirklich weiter hilft das aber nicht.


    Dann tut sich was bei ISO8859-5.so und DroidSans.ttf.

    AFAIK verwendet der VDR den Schriftsatz doch gar nicht?

    Ich würde daher auf ein Skin-Problem tippen. -> Mal mit default Skin und ohne Skindesigner-Plugin versuchen.


    Dann erscheint in dem Log am Ende ein "may leak"

    Ein "may leak"? Ich schätze eher sowas um die 10.000 ;D.


    Ich habe versucht, ob man da da grössere Blöcke ausmachen kann, aber bei der Menge sieht man den Wald vor Bäumen nicht.

    Das müsste man mal mit einem grösseren "threshold" versuchen. Evtl sogar deutlich grösser, 10 Minuten oder so. Da muss man wohl etwas rum probieren.

    Ist vielleicht der "threshold" zu niedrig und VDR hält Speicherblöcke einfach länger?

    Denke ich auch, da der Mainloop nur alle Sekunde läuft muss man den "threshold" mindestens mal auf 2 Sekunden stellen.

    Da es sich um langfristige Lecks handelt, wird mehr sicher auch nicht schaden, denke ich.


    Durch den EPG wird es aber trotzdem noch falsch positive Meldungen geben. Eventuell noch durch andere Sachen.


    Generell wird man die ersten paar Minuten nach dem Start sowieso verwerfen können und das, was beim Beenden entsteht auch.


    Ich würde es mal mit "tail -f" auf der Datei versuchen. Bei den Meldungen, die nach einer Weile Betrieb rein kommen, müssten die Interessanten dabei sein.



    Wäre praktisch wenn das jemand testen könnte der bereits einen VDR dauerhaft laufen hat. Wenn sich hier niemand findet, dann würde ich halt mal meinen HTPC eine Weile durchlaufen lassen.

    Wegen des EPG wird es mit einem Produktiv-System nicht so einfach.

    Ich hatte schon überlegt ein Testsystem, mit dummi Input, aufzusetzen und den Mainloop drastisch zu beschleunigen.

    Da erinnere ich aber nicht mehr, ob der Fehler unter den Bedingungen auftrat. Irgendwas in der Art, abgeschaltetes EPG oder so, wurde schon mal versucht.


    "pmap" schaue ich mir heute Abend an, wenn ich dafür noch Zeit finde.

    Nur pmap zeigt was an, was ich aber nicht auswerten kann

    So direkt ich auch nicht.

    Im Vergleich könnte man vielleicht was sehen.


    Also nach ~30min und dann alle 2 Stunden.

    Dazu dann am besten nach Beschreibung sortieren und dann vergleichen, wo sich was ändert.

    Irgendwo muss sich das, was man an Zuwachs von aussen mit "top" sieht, ja zeigen.


    Wenn du Glück hast, steht bei den Punkten was sinnvolles in der Beschreibung.

    Bei diesen "anon" Blöcken muss man aber wohl mit einem anderen Tool ran. Das erwähnte libleak könnte da was bringen, wenn die Beschreibung stimmt.

    Nach Auswertung der Daten scheint der Anstieg wirklich sehr gut linear zu sein.

    In Zahlen komme ich auf: 652.27Byte/Sekunde bzw. 376.22MiB/Woche.


    Jedenfalls ist es mehr als die 100Mib die bislang im Raum standen.

    Eigentlich muss der fragliche Block doch grösser oder gleich 652.27Byte sein?

    Das ist ja nicht so ganz klein, vielleicht hilft das die Suche einzugrenzen?

    Sag bitte bescheid, wenn du sie geholt hast.

    Hab ich.

    Scheint aber ein Binärformat zu sein. Da muss ich mich wohl erstmal schlau machen, wie man da an die Daten kommt.


    Das zeigt zwar die Threads aber ohne nutzbare Werte

    Auch, wenn es eine Weile gelaufen ist?

    Wenn ein Prozess geforkt wird, übernimmt er wohl das Speicherlayout des Elternprozesses. Ich hätte jetzt aber erwartet, dass sich das mit der Laufzeit ändert.

    Mit dem VDR hab ich das noch nicht versucht, aber einer der Prozesse müsste eigentlich grösser werden. Bei anderen Programmen hatte ich das schon gesehen.

    Das hilft aber nicht weiter, da die Ursache sicherlich ein Plugin ist, sonst wäre das ja verbreiteter und ich nicht immer der Einzelfall

    Versuch es mal mit:

    top -H -o RES -b -n 1 | grep -e 'vdr$'(oder besser -o VIRT?)

    Da bekommst du den Speicherverbrauch nach Threads aufgeteilt.

    Dann musst du nur schauen, zu welchem Plugin der Übeltäter gehört.




    Ausser einer eventuell etwas höheren CPU-Last sehe ich da nichts.

    Dann wäre es wohl am besten, wenn es mal jemand versucht, dem das Leck eh schon aufgefallen ist.


    Kommt man an die Rohdaten vom rrdtool eigentlich noch ran?

    Mich würde primär der lange Anstieg Oktober/November 19 interessieren.

    Das wären genug Daten, um das Rauschen durch EPG usw. zuverlässig raus zu filtern, denke ich.

    Wenn man dann annimmt, dass der Fehler aus dem Mainloop aufgerufen wird und konstant ist, wüsste man die Grösse des Speichers, die jedes mal nicht wieder freigegeben wird.

    Vielleicht findet man eher was, wenn man weiss wir gross das Objekt ist, nach dem man sucht.

    Irgendwelche Nebenwirkungen sind dadurch nicht zu erwarten?


    Beim zweiten Blick auf das Diagramm hab ich aber festgestellt, dass es sich wohl erst nach mindestens zwei Wochen ein aussagekräftiger Anstieg zeigt.

    Ich gehöre zu der Gruppe, wo der VDR normalerweise nie solange durch läuft. Da muss ich ers tmal schauen, ob ich überhaupt was erkennen kann.

    Wie kommt man dem Verursacher auf die Spur. Hab keine Programmierkenntnisse...

    Ich würde anfangen mir mal die Einzelnen VDR-Threads anzusehen. (das ging AFAIK mit "H" in top)

    Anhand der PIDs und Logfiles kann man die Threads dann den Plugins bzw. dem VDR selber zuordnen.

    Dann weiss man wenigstens wo in etwa es hängt.



    Genau genommen müsste man grep wohl noch etwas genauer formulieren.

    Vielleicht so:

    /usr/bin/top -b -n 1 | grep -m 1 -e 'vdr$'


    Damit bekomme ich dann sowas:

    Interessant, der Anstieg scheint linear zu sein und immer die gleiche Steigung zu haben.

    Damit kann man eigentlich alles, was mit User-Interaktion, Aufnahmen, EPG usw. zusammen hängt auszuschliessen.


    100MiB pro Woche sind etwa 170Byte pro Sekunde. Das könnte ein Puffer sein, der jede Sekunde erstellt und dann vergessen wird.


    Blöde Frage:

    Ist es möglich den Intervall, in dem der Mainloop läuft zu verkürzen?

    Wenn man denn doppelt so häufig laufen lässt und der Spericherverbrauch doppelt so schnell steigt, grenzt das die möglichen Fehler etwas ein.

    Muss man die Buchsen normalerweise beide anstöpseln

    Ist zu empfehlen. Wegen der Übergangswiederstände in den Steckern usw.


    Sollte aber auch nur mit einem gehen, die 12V und Masse-Kontakte sind verbunden, was ein einfacher Blick auf die Platine verrät.

    müssen die aus unterschiedlichen Strom-Schienen kommen?

    Besser nicht aus unterschiedlichen Strom-Schienen, das würde die Strom-Schienenkurzschliessen.


    Und wieviel Ampere nimmt die Karte da überhaupt maximal aus dem 6-poligen Anschluss?

    Da hängt der Tuner und die LNB-Versorgung dran.

    Je nach LNB werden da maximal 1A fliessen, bei einem Rotor vielleicht mal 2A.

    Mit einem Multischalter sind es nur die ~2,5W für die Tuner, also ~0,3A.


    Das neue NT hätte auch ein dezidiertes PCI-E-Stromkabel, allerdings wird es mit diesem noch enger als eh schon.

    Dann nimm das Kabel!

    Und ein paar Kabelbinder, damit bekommt man das alles sauber aufgeräumt.


    Je weniger Stecker und andere Geräte an dem Strang, desto besser für den Empfang. (zumindest schliesst man damit Fehlerquellen aus)