Posts by rell

    mini73 "*alloc" und "free" für C und zusätzlich "new" und "delete" für C++ oder werden Konstruktor und Destruktor im Endeffekt auch über alloc/free erfasst?

    ... bin kein C++'ler


    IMHO sollte es nicht so schwer sein, die notwendigen Wrapper zu schreiben und dann kann man auch eine Statistik füllen und abfragen. Per LD_PRELOAD wäre das wohl auch sauber einzubinden. Vielleicht schreibe ich da mal was zusammen...


    Gruß

    Andreas

    Der Grund für libleak war bei mir in erster Linie, damit man sieht, was ziemlich häufig und ständig Speicher will. Ob am Ende wirklich geleakt wurde, wollte ich erstmal gar nicht wissen. Wie zuverlässig und aussagekrüftig diese Tools sind, kann ich nicht sagen... ich habe vorher noch nie eins eingesetzt ;)


    EDIT: Wenn ich mir den letzten Eintrag aus dem Log z.B. ansehe

    Code
    1. callstack[182]: may-leak=635 (7693 bytes)
    2. expired=635 (7693 bytes), free_expired=0 (0 bytes)
    3. alloc=635 (7693 bytes), free=0 (0 bytes)
    4. freed memory live time: min=0 max=0 average=0
    5. un-freed memory live time: max=4826

    lese ich es so, dass hier wohl 7693 bytes an Speicher alloziert wurden, aber am Ende nicht gefree'd wurden?

    Das wäre für mich schonmal ein Ansatz zu schauen, ob das wirklich so ist.


    EDIT2: Wenn ich dann noch //FcFini(); // older versions of fontconfig are broken - and FcInit() can be called more than oncesehe, sieht das auf den ersten Blick für mich als Laien, oder jemanden, der noch nicht genau in den Code geschaut hat, verdächtig aus :p

    Ich komme mit den "Leck-Detektoren" auch nicht klar. Ich habe bei markad genau so eine Logging Funktion mal eingebaut. Jedes alloc/new wird mit dem Objektnamen in ein Array geschrieben, jedes free/delete löscht den Eintrag aus dem Array. Am Programmende wird das gelogged, was noch im Array drin ist.

    War zwar erst mal ein großer Aufwand das überall einzubauen, deckt jetzt aber neue Leaks sofort auf.

    Das Ganze ist aus Performance Gründe natürlich per default über Compiler Direktive aus.

    Nur weiter gedacht: Der Detektor von oben hängt sich ja zwischen jedes alloc und free, wenn ich es richtig verstanden habe. Könnte man den nicht so anpassen, dass er genau das macht? Stelle ich mir einfacher vor, als zu versuchen, alles im Programm selbst zu suchen? Dh. ein Array mit dem pointer und dem zugewiesenem Speicher füllen und leeren und sich am Ende ansehen, was übrig bleibt? Oder auch mal zwischendurch schauen, was im Array so drin ist?


    Gruß

    Andreas

    Ich habe den code von libleak mal angepasst, damit nur jeder 100. Fund geloggt wird. libleak war so eingestellt, dass es sich erst nach 1h eingeschalten hat und auch die allocs am Programmstart habe ich überspringen lassen. Alles, was in vdr gelinkt ist ("ldd vdr") habe ich auf die Blacklist. Der VDR ist eine gute Stunde gelaufen.


    Ich komme erst später dazu, genau reinzuschauen, aber wenn jemand Zeit und Interesse übrig hat, kann er ja mal reinschauen... Vielleicht findet sich was auffälliges. Viel Spaß ;)

    Das Log liegt hier: http://lima.imkreisrum.de/vdr/


    Gruß

    Andreas

    Guter Tip, für mich war es erstmal interessant zu sehen, wer überhaupt zur Laufzeit Speicher haben will. Wenn man die alle durchgeht, sollte der Kandidat ja dann dabei sein?


    Zu den leeren Strings kann ich nichts sagen, das kann Klaus wohl beurteilen.


    Hier mein Speicherverbrauch über einen Tag protokolliert:


    Rund 12MB/24h. Etwas weniger als bei den Kollegen. Ich bin mir auch nicht mehr sicher, ob das bei aktiviertem EPG-Scan nicht normal ist, wenn ständig reallocs stattfinden? Ich habe übrigens den Code so geändert, dass kein Speicher für leere Strings beansprucht wird.


    Gruß

    Andreas

    Ich beobachte auf meinem Server auch eine ständig steigende Speicherauslastung. Bei mir sind es hier ca. 500kB/h.

    Die beiden Patches (delete-d + eit)habe ich drin. Ich habe auch mit libleak gestartet, was nach 1h Laufzeit begann zu analysieren. Gibt natürlich jede Menge logs und ich bin noch nicht durch... Was mit aber aufgefallen ist, dass hier ganz oft 1byte alloziert wird, auch wenn strlen(ShortText) == 0 ist. Wäre es nicht richtig, es so zu machen, wie hier?

    Ich habe ein paar allocs aus dem libleak-log rausgepickt -> https://pastebin.com/raw/Tsjyp43M Das sind überwiegend reallocs. callstack[2957]z.B. ist da richtig gut dabei. Vielleicht hilfts ja.


    Gruß

    Andreas

    Ich lade mir immer LE runter und nehme die da angegebenen Versionen von Kernel und FFmpeg mit den dazu gehörigen Patches aus LE. Das hat immer funktioniert.

    Ist hier auch so. Und wenn die kernel oder ffmpeg patches (noch) nicht zu den Versionen passen, kann man sie updaten wie oben geschrieben, damit “git am“ klappt.


    Bei ffmpeg installiere ich übrigens keins von den Paketen aus der Anleitung. Meine config ist auch deutlich schmaler:

    Wie zille schon geschrieben hat, kernel und ffmpeg muss zusammenpassen. Auch auf die header achten. Wenn man sich an LE hält, sollte es klappen.

    Kernelversion

    FFmpeg Version

    Kernel patches

    FFmpeg patches 1

    FFmpeg patches 2

    FFmpeg patches 3


    ... sollte als Kurzzusammenfassung eigentlich ausreichen. Die kernel config vor dem Bauen halt noch checken...

    Gruß Andreas

    Für den Fall, dass die Patches von LE noch nicht auf die verwendete Kernel-Version angepasst wurden, kann man das so selber machen. Wusste ich vorher nicht...

    gentoo-vdr Hast du denn keine Möglichkeit, den Kernel woanders zu bauen? Da sitzt du ja ewig da ;)

    rookie1 Hab was eingecheckt. Kannst du das nochmal testen? Funktioniert die OSD Anzeige überhaupt bei dir?

    Ich glaube, ich muss mir die drm-Initialisierung mal vornehmen, wenn ich Zeit habe. Das passt noch nicht mit der Reihenfolge der drm planes.


    Gruß

    Andreas

    Ok danke. Hilft leider nicht. Sehe nur den gleichen Fehler -22 (Invalid argument).

    Irgendwas passt nicht mit drm und hängt damit zusammen, dass zpos beim RPI nicht geht. Ich muss da erst ein bißchen nachdenken und melde mich wieder ;)

    Nochmal ich, vielleicht ist "1" zu wenig. Wenn du es noch mal mit "echo 0xf > /sys/module/drm/parameters/debug"

    versuchen könntest, wärs top. Dann belästige ich dich auch nicht mehr ;)


    Gruß

    Andreas

    Hm, bei Nov 26 15:27:16 raspberrypi kernel: [ 8064.568030] [drm:drm_stub_open [drm]] gehts los und bis zum Ende sehe ich nur DRM_IOCTL_PRIME_FD_TO_HANDLE,DRM_IOCTL_MODE_ADDFB2,DRM_IOCTL_MODE_ATOMIC , was bei Video normal sein sollte.

    Bin mir aber auch nicht sicher, ob der Fehler dort auftaucht, Sinn würde es aber machen, wenn der ioctl nicht klappt.

    Vielleicht kannst du nochmal schauen, und mit dem Zeitstempel im syslog vergleichen. Danke!

    Danke. Das passt. Ich weiß womit es zusammenhängt, aber noch nicht worans hapert. Schau ich mir später mal an.

    Hast du das mit /sys/module/drm/parameters auch mal probiert?


    Gruß

    Andreas

    Ja, passt. Hab mich falsch ausgedrückt, die logs sind schon da.

    Aber da es an drm hakt, interessieren mich die Logs vom VDR Start bis zum abort. Irgendwas fehlt dem atomic commit in den Parameter bzw. ist falsch. Ich habe leider keinen RPI und am Allwinner habe ich keine Probleme.


    Gruß

    Andreas