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.

    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • 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 * (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.

    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • @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
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • Quote

    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.

    Edited once, last by RHS (February 18, 2024 at 8:42 PM).

  • 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

    Mein (neuer) VDR:

    Software:
    Debian Wheezy mit Kernel 3.14
    VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
    noad 0.8.6

    Hardware:
    MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
    32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
    TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
    Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
    PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

  • 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?

    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • 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.

    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • 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:

    mdre
    January 2, 2021 at 10:05 AM

    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

    Mein (neuer) VDR:

    Software:
    Debian Wheezy mit Kernel 3.14
    VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
    noad 0.8.6

    Hardware:
    MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
    32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
    TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
    Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
    PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

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

    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • 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.

    Files

    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • 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
  • Mein Fehler.

    Files

    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

  • 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?

    Files

    Gruss
    SHF

    Mein (neuer) VDR:

    Software:
    Debian Wheezy mit Kernel 3.14
    VDR 2.0.7 & div. Plugins aus YaVDR-Paketen
    noad 0.8.6

    Hardware:
    MSI C847MS-E33, onboard 2x1,1GHz Sandybridge Celeron 847, 4GiB RAM
    32GB SSD (System), 4TB 3,5" WD-Red HDD (Video)
    TT FF DVB-S 1.5 FullTS-Mod PWM-Vreg-Mod, DVB-Sky 852 Dual DVB-S2
    Das ganze im alten HP Vectra VLi8-Gehäuse versorgt von:
    PicoPSU-160-XT und Meanwell EPP-150 im ATX-NT-Gehäuse

Participate now!

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