Compile Warnings in vnsiserver

  • Hier mal der erste Teil der Änderungen als Patch.

    Das läuft hier auch stabil, aber allzu lange habe ich das bislang nicht getestet.


    Der Patch ist, sofern ich nichts übersehen habe, soweit auch komplett und sollte, eigentlich alle Abstürze beseitigen.

    Was noch fehlt ist der Teil, der die Änderung aus dem Menü in Kanallist bringt. Da ist momentan noch ein Neustart des VDR nötig.


    Anzuwenden auf die unveränderten channels.* vom VDR 2.6.6.

    Files

    Gruss
    SHF


  • Vielleicht wäre sogar besser, die Kombi aus Name und Source ganz aus cChannel zu entfernen und nur im OSD an der benötigten Stelle zusammen zu bauen.

  • wirbel mit deinem vnsiserver-crashes git aus #156 gibt es folgenden compile error:


    Code
    g++ -g -O3 -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-wi/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();
          |   ^~~~
  • Hmm, ich hatte wohl nicht die letzte Version vom Patch erwischt.


    mach mal

    git pull


    und probier noch einmal.

  • Hab das mal gebaut bei der Anwendung des patches aus #169 auf einen Git clone des vdr aus vdr-projects war der Hunk:


    Code
    @@ -60,7 +60,6 @@
       provider = strdup("");
       portalName = strdup("");
       memset(&__BeginData__, 0, (char *)&__EndData__ - (char *)&__BeginData__);
    -  nameSourceMode = 0;
       parameters = "";
       modification = CHANNELMOD_NONE;
       seen         = 0;

    schon vorhanden. Patch wollte diesen reverten.


    Nach Löschung dieses Hunk lies sich der Rest patchen.

    crashed jetzt dauernd. Hier der Backtrace.


    Code
    #0  __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:40
    #1  0x00007fef775322b7 in cSatipDevice::IsTunedToTransponder (channelP=0x8552e0, this=0xcf4030) at /usr/src/packages/BUILD/vdr-2.6.6-test/include/vdr/tools.h:188
    #2  cSatipDevice::IsTunedToTransponder (this=0xcf4030, channelP=0x8552e0) at device.c:334
    #3  0x00000000004a64e4 in cDevice::GetDeviceForTransponder (Channel=0x8552e0, Priority=Priority@entry=-99) at device.c:425
    #4  0x0000000000489b8a in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/packages/BUILD/vdr-2.6.6-fi/timers.h:67
  • Ich hab noch die nicht mehr benötigten "mutable" sowie die Deklaration von nameSourceMode entfernt.

    Stimmt, wo Du es schreibst, ich hatte in der channels.h gar nicht geschaut, ob da was aufzuräumen ist.


    Dabei fällt mir auf, dass ich das "NULLen" der Strings noch komplett in die neue Funktion rein ziehen wollte, das aber nur teilweise erledigt hatte.

    Beim Bearbeiten fiel mir auf, das es ist sinnvoll wäre den Speicher der Strings frei zu geben, wenn man sie nicht mehr benötigt und mein Konzept deshalb etwas geändert. Habe dann aber irgendwie vergessen den "oberen Teil" anzupassen.


    Ich habe die Kleinigkeit jetzt noch ergänzt. Der angehängte Patch funktioniert bei mir auch einwandfrei, inklusive umschalten der Anzeige im Menü.


    Hab das mal gebaut bei der Anwendung des patches aus #169 auf einen Git clone des vdr aus vdr-projects war der Hunk

    Versuch es mal mit einem

    git clone https://github.com/wirbel-at-v…tal/vdr-cChannel-Name.git

    und dann

    git revert a63e855(und Editor beenden)

    Der erste hunk geht bei mir auch nicht rein, das kann man aber ignorieren, da das Ergebnis stimmt.

    Bei mir läuft das so jedenfalls ohne Absturz. Zumindest einige Minuten, länger habe ich es noch nicht versucht.

    Files

    Gruss
    SHF


  • Ich hab das mal auf https://github.com/wirbel-at-vdr-portal/vdr-cChannel-Name bis patch #4 eingepflegt zum besseren Testen.

  • Ich würde vorschlagen UpdateNameSource() privat zu halten:


  • Nur so als Einwurf:

    Die Crashes mit control und remote sollten mit diesen Fixes nicht weg sein, oder?

    Denn die sind nach wie vor vorhanden, auch mit dem Patch.

  • nobanzai:


    Das kam mir auch schon in den Sinn, ob das vllt. die gleiche Ursache hat.

    Beide Plugins sind schon ewig nicht mehr angefasst worden, weil sie eben zu 100% stabil liefen und es keine feature requests oder dringende Änderungen in VDR selbst gab. Neuer VDR -> neu bauen && fertig. Mit 2.6.6 gibt es zu beiden Plugins problem reports, die nicht verstanden sind.

    Die letzte echte Änderung in control war Apr 3, 2021.


    Vom Prinzip her müsste das genau wie hier mit Geduld, Testern und detaillierten Infos / cores debugged werden.

    Ich selbst nutze control regelmäßig beim debuggen meiner Plugins mit einem (fast) ungepatchten VDR, aber ich kann hier leider keine Abstürze provozieren.


    Kann ich auch mit vnsiserver nicht, aber nutze das Plugin eigentlich nicht selbst.

  • Ich glaube, so wäre korrekter.

    Da muss ich nochmal nachhaken. Wieso wurde aus der 2 eine 1?

    Eigentlich müsste es doch sogar 3 sein. Wenn sprintf() aufgerufen wird, ist das erste Byte von buffer schon mit dem Code ('S', 'T',...) belegt, also -1. Es muss aber noch Platz bleiben für das 'W' oder 'E' (-2), sowie für die abschließende 0 (-3).

    Die Prüfung auf 'l < (sizeof(buffer) - 1' ist m.E. unnötig, da das snprintf() schon sicherstellt.

    Korrektur: Hab gerade nochmal 'man snprintf' gelesen.

    Also eher so (oder übersehe ich was?):

  • Vom Prinzip her müsste das genau wie hier mit Geduld, Testern und detaillierten Infos / cores debugged werden.

    Ich selbst nutze control regelmäßig beim debuggen meiner Plugins mit einem (fast) ungepatchten VDR, aber ich kann hier leider keine Abstürze provozieren.


    Kann ich auch mit vnsiserver nicht, aber nutze das Plugin eigentlich nicht selbst.

    Also die Core-Infos sind immer noch dieselben, die an dem Fred hängen.

    Gerade nochmals getestet, ist genauso wie zuvor.

    Ich kann aber gerne jede Info liefern, die benötigt wird - ich brauche eins der beiden Plugins dringend, weil ich sonst meine headless Server nur schwer konfigurieren kann.

    Leider erkenne ich zwar C++, wenn ich es sehe, und wenn das nichts allzu C++ Spezifisches ist, kann ich ggf. sogar Fehler finden, aber sobald es in hardcore C++ geht, bin ich raus 8-<

  • Oh, ich hatte das schon vergessen..


    Da muss ich nochmal nachhaken. Wieso wurde aus der 2 eine 1?


    snprintf darf bis zu (sizeof(buffer) - 1) bytes schreiben, da ein byte weg ist für (Code & st_Mask) >> 24 und der pointer nicht mehr bei buffer beginnt.

    Wenn kein byte mehr übrig war für das \0, ist der string nicht mehr terminiert. Das führt dann zu l < (sizeof(buffer) - 1). Kleiner.

    Das byte für die nachfolgende Zeile fehlt mit dem W oder E dann aber noch - mein Fehler, sorry.

    Also

    Code
    if (l < (sizeof(buffer) - 2) && l > 0) {

    alternativ deine korrekte Lösung.

    Code
         int l = snprintf(q, sizeof(buffer) - 2, "%u.%u", abs(n) / 10, abs(n) % 10); // can't simply use "%g" here since the silly 'locale' messes up the decimal point
         if (l > 0) {

Participate now!

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