Compile Warnings in vnsiserver

  • Mit obigen Patch von Wirbel bleibt nur noch eine Warnung:

    ich gabe diesmal wie zu erkennen ist die Compileroptionen angepasst. Wie oben von SHF angeregt. DEBUG_LOCKING ist aus

  • Mit 13.2.0 kann ich keine Warnungen mehr produzieren.

  • ich habe den Patch von oben mit 13.1.0 getestet und auch hier sind keine Warnungen mehr.

    (VDR) NUC11PAH & GEEKOM MINI-IT11-11. Generation * BM2LTS * DD NET S2 Max * NC * (Sound) Cinebar Lux Set * (Stream) Apple TV 4K (2022) *

    (Light) PHILIPS Hue Play HDMI Sync Box & Gradient Lightstrip * (OLED TV) LG OLED65G29LA

  • Ich fürchte ja das wird damit noch nicht erwischt sein, ich hoffe dass jmd testet und mit logs berichtet.

    Aber vllt eine erste Verbesserung.

  • @warnings:


    Code
    streamer.c:57:17: warning: member ‘cLiveStreamer::m_Event’ is used uninitialized [-Wuninitialized]
    57 |  , m_VideoInput(m_Event)
    |                 ^~~~~~~

    Der Constructor von m_VideoInput wird mit dem lokalen class member m_Event aufgerufen,

    aber m_Event ist selbst noch nicht sicher erzeugt. Deswegen erst den m_Event constructor aufrufen und _dann_ den Constructor von m_VideoInput.

    Falsche Reihenfolge.


    g++ hat recht.





    Hier wird für jeden member von (*whitelist) eine lokale Kopie innerhalb des for loop angelegt.

    Das kostet Speicher und seeeehr viel Zeit, und hofft darauf, dass die Kopie wirklich alle Daten kopiert, etc.


    Code
    channelfilter.c: In member function ‘void cVNSIChannelFilter::StoreWhitelist(bool)’:
    channelfilter.c:188:23: warning: loop variable ‘i’ creates a copy from type ‘const cVNSIProvider’ [-Wrange-loop-construct]
    188 |       for (const auto i : *whitelist)
    |                       ^
    channelfilter.c:188:23: note: use reference type to prevent copying
    188 |       for (const auto i : *whitelist)
    |                       ^
    |                       &




    videoinput.c:468ff


    Hier gibt es gleichzeitig mehrere Probleme.

    Zum einen wird von jedem member von sPool (seehr laaangsam) eine lokale Kopie im Geltungsbereich des for loop angelegt.

    Das alleine garantiert nicht, dass in der Zwischenzeit aber nicht der 'echte' cDummyReceiver nicht zerstört wurde -> race.

    Und zusätzlich könnte auch der shared pointer dabei sein zerstört zu werden 'expired'. Aber selbst wenn nicht, kann ja 'recv' immer noch ein NULL pointer sein.


    Eigentlich haben die gcc Entwickler wirklich gute Arbeit geleistet.

    Code rausgefischt mit Warnungen, der schwer zu lesen ist..


    Code
    inlined from ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’ at videoinput.c:469:28:
    /usr/include/c++/13/bits/atomic_base.h:505:31: warning: ‘unsigned char __atomic_load_1(const volatile void*, int)’ writing 1 byte into a region of size 0 overflows the destination [-Wstringop-overflow=]
    505 |         return __atomic_load_n(&_M_i, int(__m));
    |                ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
    In static member function ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’:
    cc1plus: note: destination object is likely at address zero
  • Zitat

    Mit 13.2.0 kann ich keine Warnungen mehr produzieren.

    ich benutze :

    gcc (SUSE Linux) 13.2.1 20240206 [revision 67ac78caf31f7cb3202177e6428a46d829b70f23] da gibt es dann o.g. #82 Warnung.

  • Zu: warning: loop variable ‘i’ creates a copy from type...


    Dazu, mir das wirklich mal anzusehen, war ich bislang nicht gekommen, aber ich hatte mal nach so ähnlichen Stellen gesucht.

    Da kamen dann noch 2 weitere, die keine Warnung verursacht hatten:

    channelfilter.c Zeile 222

    vnsiclient.c Zeile 1410

    Eigentlich müsste da das "&" auch Sinn machen, meine ich, es sei denn std::set mal wieder irgend ein Sonderfall.

    Ohne das wirklich verstanden zu haben, wollte ich da aber besser nichts ändern

    Gruss
    SHF


  • Mit dem Patch aus #81 hatte ich zwei abstürze, so das vdr neu gestartet wurde:


    1. Absturz:


    2. Absturz:



    Es gibt diesmal keine malloc Meldung aber die Sequenz vor den Neustart ist noch die gleiche:


    Stream changes

    Requesting clients to reload channels list

    Absturz u. Neustart


    Meine channel list ist groß ca. 3500 Einträge lang, die Satip Einträge von DVB-S 19,2, und DVB-C vom Kabel.

  • Hast du auch neue Backtraces, z.B. von automatisch geschriebenen cores?

  • Hier ein aktueller vollständiger coredump


    Ich hoffe es ist hilfreich. Wenn zur Parametrisierung andere Anforderungen da sind bitte ich um eine Hinweis. Im folgendem der

    Syslog Teil vor dem crash.


  • Es knallt immer wieder in vnsiclient.c:1148 und den Zeilen danach, kurioserweise immer wieder


    cVNSIClient::processCHANNELS_GetChannels(), dann cChannel::Name(), dann cString::sprintf(), in cString::sprintf() wird vasprintf() aufgerufen, dann schafft es vielleicht nocht die Fehlermeldung ins log, bevor der Prozess beendet wird. Das sind dann die Zeilen im for loop in


    Code
    cVNSIClient::processCHANNELS_GetChannels


    Auffällig ist auch, dass zwei threads in der gleichen Funktion cVNSIClient::processCHANNELS_GetChannels sind.

  • Nur mal als Historie falls nicht bekannt. Eventuell hilft es etwas beim Debuggen.

    VNSI-Server wurde ursprünglich mal hier vom ursprünglichen Entwickler gepflegt: https://github.com/FernetMenta/vdr-plugin-vnsiserver

    Etwas später wurde die Entwicklung zeitweise hier fortgeführt: https://github.com/mdre77/vdr-plugin-vnsiserver


    Und im zweiten Repo wurde, soweit ich weiß, vor allem zusätzliche Threads eingeführt um diverse Bugs zu fixen:


    Vielleicht ist in diesem Schritt vom "Original-Code" zu "verbesserter Code" irgend ein Bug mit eingebaut worden der jetzt erst für Probleme sorgt.

  • Auffällig ist auch, dass zwei threads in der gleichen Funktion cVNSIClient::processCHANNELS_GetChannels sind.

    Endlich sieht man das mal, vermutet hatte ich das schon die ganze Zeit.

    Grundsätzlich ist daran aber, bei zwei Clients, nichts auszusetzen.


    Daher auch der Vorschlag sich das Locking mal anzusehen. Vielleicht versteht man dann besser was da passiert.

    Gruss
    SHF


  • M-Reimer , würdest du die Patche in diesem thread deinen fork aufnehmen? Wäre gut, wenn das zentral ist.

  • Der folgende patch ändert processCHANNELS_GetChannels() so,

    dass

    - Channels auf NULL geprüft wird

    - cStateKey::Remove() nur ausgeführt wird, wenn Channels != NULL

    - vdr < 1.3.1 aus der Funktion entfernt wird und die Zeilen im if eingerückt werden.


    Damit ist der Lock ganz genau so, wie hier beschrieben.

    Aber am eigentlichen Problem geht das immer noch vorbei.

  • Mit obigen Patch bekomme ich folgenden Compile Error:


    Code
    g++ -g -O1 -Wall -march=goldmont-plus -Woverloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -std=c++11 -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"vnsiserver"' -DVNSI_SERVER_VERSION='"1.8.3"' -I/usr/src/packages/BUILD/vdr-2.6.6-test/include -o vnsiclient.o vnsiclient.c
    vnsiclient.c: In member function ‘bool cVNSIClient::processCHANNELS_GetChannels(cRequestPacket&)’:
    vnsiclient.c:1206:3: error: ‘resp’ was not declared in this scope
     1206 |   resp.finalise();
          |   ^~~~
    make[1]: *** [Makefile:86: vnsiclient.o] Error 1
    
    *** failed plugins: vnsiserver
  • An Anfang hatte ich auch mal überlegt, das StateKey-Geschichte komplett durch die "convenience macros" zu ersetzen. (Primär um sich das nicht näher ansehen zu müssen ;) )

    In vnsiclient.c ging es zwar, in status.c bin ich mit den Konzept aber gescheitert und habe es deshalb nicht weiter verfolgt. Im Anhang trotzdem mal die Änderungen in vnsiclient.c.

    Am Problem ändern wird das aber ziemlich sicher nichts.


    Vielleicht versteht man dann besser was da passiert.

    In dem zweiten Coredump sieht man doch mehr als bisher, man muss nur mal genau lesen...


    Beide Threads von cVNSIClient::processCHANNELS_GetChannels haben den Readlock bekommen, oder sie verhalten sich zumindest so.


    Der Eine hängt Zeile 1185 in VNSIChannelFilter.PassFilter(*channel). (Da gibt es nur die eine Zeile, die in Frage kommen könnte.)


    Der Zweite "böse" hat mal wieder mit channel->Name() einen Chrash ausgelöst.

    Beim Suchen der Zeile ist mir Aufgefallen, dass zwei in Frage kommen könnten: 1181 und 1190.

    Jetzt wäre mal interessant, ob es wieder in 1181 war.

    Die Zeilennummern konnte ich in lesbarer Form nicht erkennen, bekommt man die irgendwie auch noch raus?

    Dateien

    Gruss
    SHF


Jetzt mitmachen!

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