Compile Warnings in vnsiserver

  • Dann war's das wohl erstmal mit Kodi und VDR. Das einzige das ich bestätigen kann, ist, dass ich diese Warnings auch sehe.



    Und damit bin ich mit meinem Latein auch schon am Ende. Absolut Null Ahnung was der Compiler damit sagen will.

  • Scheint was schwierigeres zu sein. Vielleicht hilft es, stückweise Infos zu sammeln. Mit gcc 11.1 gibt es diese Warnungen nicht.



    Der Compiler sagt, soweit ich lesen kann ..


    - es gibt in videoinput.c eine Klasse cDummyReceiver

    - diese Klasse hat eine member Funktion bool BeenDetached() in videoinput.c Zeile 428, welches den private member std::atomic<bool> m_BeenDetached zurückgibt. Also ist diese Funktion wohl shared zwischen mehreren threads.

    Der compiler inlined das wegen Optimisation, so dass der private member std::atomic<bool> m_BeenDetached direkt zurück gegeben wird.

    - mit diesem member m_BeenDetached gibt es wohl ein Problem in cDummyReceiver::Create(cDevice *), damit wäre man dann wohl bei Zeile 468

    Code
        if (!recv->BeenDetached() && recv->Device() == device)


    Zwei Fragen wären interessant, der loop geht über alle cDummyReceiver in s_Pool:


    Code
    for (auto p : s_Pool)


    aber evtl wäre auch möglich um Kopien der member von s_Pool zu vermeiden


    Code
    for (auto& p : s_Pool)


    Ich habs nicht ausprobiert, ich nutze vnsi nicht.


    Irgendwie endet der lesbare code in Zeile 467

    Code
    auto recv = p.lock();

    Ich verstehe nicht, woher der member lock() kommt.

  • Das "p" ist hier definiert:

    vdr-plugin-vnsiserver/videoinput.c at 57e4c71faae7414e15d3e36c4cfb4e7d7f518f72 · vdr-projects/vdr-plugin-vnsiserver
    VDR plugin to handle XBMC clients. Contribute to vdr-projects/vdr-plugin-vnsiserver development by creating an account on GitHub.
    github.com


    Und wenn man mal nach diesem "weak_ptr" sucht, dann findet man auch das "lock"

    std::weak_ptr<T>::lock - cppreference.com


    Vielleicht hätte man beim Entwickeln von vnsiserver nicht ganz so abgrundtief in die C++-Trickkiste greifen müssen. Dann wäre der Code vielleicht sogar lesbar geblieben :§$%

  • std::weak_ptr<T>


    A shared_ptr which shares ownership of the owned object if std::weak_ptr::expired returns false. Else returns default-constructed shared_ptr of type T.


    Möglicherweise ist das Object gelöscht worden, so dasss der return value 'false', aka '0' ist. Aber damit kenne ich mich nicht aus.

  • Ich habe mal noch eine Weile gesucht und immer wieder die Info gelesen, dass diese Warning wohl schon mehrfach ein "False Positive" war. Ich würde mal wagen zu behaupten das diese Warnung nicht 100%ig sicher die Ursache für den seit neuestem auftretenden Crash ist:


    malloc(): unaligned tcache chunk detected


    Und selbst mit einem Backtrace könnte ich die Ursache selbst nicht finden. Das Kauderwelsch in Backtraces konnte ich eigentlich noch nie lesen.


    Alles ein bisschen ernüchternd. Da VNSI eigentlich echt gut funktioniert hatte, hatte ich Hoffnung, dass es reicht das immer nur an neue VDR-Versionen anzupassen. Das bis vor kurzem funktionierender Code dann plötzlich nicht mehr funktioniert stellt für mich das ganze Konzept "VDR" in Frage.

  • Wäre schön, mal den ganzen gdb bt zu sehen.

  • Ich hebe gerade den vdr-2.6.6 und vnsiserver wie oben mit diesen Compiler:

    Code
    g++ (SUSE Linux) 7.5.0
    Copyright (C) 2017 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


    neu kompiliert. Dabei habe ich keine Warnings mehr bekommen. Einen Crash wie oben mit vielen channel wechsel und mehren Kodi vnsi clients

    gab es ebenfalls nicht.


    Einen g++ 11 habe ich nicht installiert, mit g++ 12 gibt es die gleichen Probleme wie mit g++13.


    Der Warntext

    Code
    writing 1 byte into a region of size 0 overflows the destination

    könnte vieeleicht die Ursache des malloc crash sein?

  • wirbel Wäre für mich schon eine etwas größere Sache weil ich alles selbst kompiliere. Und ich habe eigentlich auch nur ein System das für einen Test in Frage kommt, welches gleichzeitig das Produktivsystem ist. Da ich bei Arch eigentlich nur eine Option habe was Compiler angeht (gcc 13.2.1) und damit wohl ziemlich sicher mein Produktivsystem lahmlege, würde ich erstmal abwarten ob sich jemand anderes findet der einen Backtrace bauen kann.

  • Selbe Situation hier. :)

  • Ich habe wie Warnung gerade auch in den Buildlogs des vnsiserver für Ubuntu 24.04 gesehen - da ich immer Debug-Pakete mit erzeugen lasse, sollte es nicht allzu schwer sein an einen Backtrace zu kommen.


    RHS: Was muss man den tun, um so einen Crash möglichst schnell zu provozieren? Für mich wäre es am einfachsten einen headless VDR auf einem Ubuntu 24.04 aufsetzen, dem einen Tuner zu geben und dann einen KODI-Client mit vnsi PVR-Addon von einem anderen Rechner darauf zugreifen lassen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • seahawk1986

    Was man genau tun muss weiß ich nicht so richtig. Auf meinem System habe ich dieses Problem verstärkt seit dem Upgrade auf vdr-2.6.6.
    Ich betreibe den vdr headless mit satip von wirbel, live von https://github.com/MarkusEh/vdr-plugin-live, dvbapi. Darauf greife ich über mehrere Clients mit Kodi (libreelec) zu.


    Vor 2.6.6 trat der crash alle paar Tage beim Umschalten auf. Seit 2.6.6 tritt der Crash manchmal schon nach Neuladen des Systems und Auswahl eines Senders auf. Ich habe keine DVB Karten im Einsatz sondern hohle mir die Sender über Satip einmal DIGIBIT mit anderer Firmware für SAT und Fritzbox DVB-C für Kabel Sender.


    Ich compiliere alles selbst. Auf einem OpenSuse Tumbleweed System.



    PS: meine obige Aussage bezüglich G++ 7.5.0 muss ich relativieren es gab auch einen Crash aber seltener.

  • Ich mach das meist in gdb. Sowas wie


    Code
    ulimit -c unlimited
    gdb --args <deine normale vdr befehlszeile hier mit allen Plugins>


    Danach mit der Taste r den Prozess starten und auf den Crash warten.


    Die letzten Zeilen vor dem crash bekommst du dann im gdb Fenster mit


    bt full

  • In meinem debian mache ich:

    Code
    sudo coredumpctl list
    sudo coredumpctl debug <PID>   (PID aus der Liste)
    bt full


    So kann ich auch ein bt all machen, wenn der VDR Server "zufällig" abgestürzt ist.

    Leider geht das in Ubuntu (meines Wissens) anders. In SuSE vermutlich wieder anders ...

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Ich mache das unter Suse wie folgt

    Code
    cd /home/<Dein User>
    ulimit -c unlimited
    gdb /usr/local/bin/vdr -c core
    set logging file backtrace.txt
    set logging on
    run
    ▪ nach dem Absturz
    bt full

    Stefan

  • Leider geht das in Ubuntu (meines Wissens) anders.

    Da kann man sich auch systemd-coredump nachinstallieren, wenn man das nicht über das vorinstallierte apport machen will.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das "p" ist hier definiert:

    Bin ich der Einzige, der die for-Schleife in Zeile 456 merkwürdig findet?


    Genauer gesagt, das autp p und das aus mehreren Gründen.

    - p existiert, wie gesagt, bereits.

    - Eine auto Variable müsste doch eigentlich gleich initialisiert werden?


    Entweder ist das ein genialer C++-Hack, den ich nicht verstehe, oder da ist was faul.


    Ehrlich gesagt, wüsste ich jetzt auch nicht sicher, was bei dem Konstrukt raus kommt.

    Gefühlt würde ich aber mal auf eine uninitialisiertes int p in der Schleife tippen.

    Ich hätte das auto p jedenfalls einfach weg gelassen, also for ( : s_Pool) oder gleich while (s_Pool) verwendet.

    Gruss
    SHF


  • p existiert, wie gesagt, bereits.

    Aber nur in dem Closure davor für das erase - remove_if Idiom (https://www.geeksforgeeks.org/erase-remove-idiom-in-cpp/), oder? Und selbst wenn müsste die Deklaration für die range-based for loop (https://en.cppreference.com/w/cpp/language/range-for) eine vorhandene Variable überdecken (shadowing).


    p müsste dann in der range-base for loop eine Kopie des jeweils durchlaufenen std::weak_ptr<cDummyReceiver> aus dem Vector sein, was für mich so aussieht, als ob das den Schutz, den man durch das Locking erreichen will, aushebeln könnte, weil die beiden weak_ptr das gleiche Objekt verwalten - wäre da ein &p nicht besser?


    Ich hätte das auto p jedenfalls einfach weg gelassen, also for ( : s_Pool) oder gleich while (s_Pool) verwendet.

    Aber das p wird doch gebraucht, um den Receiver aus dem weak_ptr zu bekommen, der von der Methode ggf. zurückgegeben werden soll: https://github.com/vdr-project…/master/videoinput.c#L467

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Aber nur in dem Closure davor für das erase - remove_if Idiom [...]

    Stimmt, da habe ich nicht aufgepasst. Das hat mich aufs Glatteis geführt.

    Gruss
    SHF


Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!