GIT-Archiv für VDR auf http://git.tvdr.de

seahawk1986 · Dec 15th 2020

Quote from kls

Bitte ausgiebig testen.

Wer das mit Ubuntu 20.04 machen will: in https://launchpad.net/~seahawk…/ubuntu/vdr-2.4.5-patches habe ich gestern Abend Pakete bauen lassen (die Pakete für autostart, pvrinput und externalplayer lasse ich gleich noch gegen den neuen VDR bauen).

HagenS · Dec 15th 2020

Quote from seahawk1986

Wer das mit Ubuntu 20.04 machen will: in https://launchpad.net/~seahawk…/ubuntu/vdr-2.4.5-patches habe ich gestern Abend Pakete bauen lassen (die Pakete für autostart, pvrinput und externalplayer lasse ich gleich noch gegen den neuen VDR bauen).

Es gibt ein Probleme mit dem menuorg-Plugin - Siehe hier: yavdr experimental für Ubuntu 20.04 (yavdr ansible @ focal)

wirbel · Dec 15th 2020

plugin.c:235 -> falls destroy == nullptr, ist das kein Fehler und cDll::~cDll() abgefangen.

destroy = (destroy_t *)dlsym(handle, "VDRPluginDestroyer");

--error = dlerror();

kls · Dec 16th 2020

wirbel stimmt.

Diff

--- plugin.c    2020/12/13 10:56:36     4.3
+++ plugin.c    2020/12/16 09:19:02
@@ -233,7 +233,7 @@
      if (!error && create) {
         plugin = create();
         destroy = (destroy_t *)dlsym(handle, "VDRPluginDestroyer");
-        error = dlerror();
+        // no call to dlerror() here - will be checked in cDll::~cDll() for backwards compatibility
         }
      }
   if (!error) {

Display More

kls · Dec 16th 2020

Quote from glotzipapa

Ich würde gerne mein Veto einlegen. Seit diesem Commit

http://git.tvdr.de/?p=vdr.git;…1139b7b842b6de56bf88d8b1c

funktionieren meine Raspis nicht mehr korrekt.

HelmutB kannst du dazu was sagen?

wirbel · Dec 16th 2020

Alternativ:

Diff

--- plugin.c    2020/12/13 10:56:36     4.3
+++ plugin.c    2020/12/16 09:19:02
@@ -233,7 +233,7 @@
      if (!error && create) {
         plugin = create();
         destroy = (destroy_t *)dlsym(handle, "VDRPluginDestroyer");
         error = dlerror();
+        if (error) {
+           error = NULL;
+           isyslog("plugin %s: missing symbol VDRPluginDestroyer(), please rebuild", fileName);
+           }
         }
      }
   if (!error) {

Display More

kls · Dec 16th 2020

wirbel noch besser!

HelmutB · Dec 16th 2020

Quote from glotzipapa

ch würde gerne mein Veto einlegen. Seit diesem Commit

http://git.tvdr.de/?p=vdr.git;…1139b7b842b6de56bf88d8b1c

Quote from kls

kannst du dazu was sagen?

Etwas schwierig zu sagen. ich habe derzeit auch keinen 32-Bit VDR um es zu vergleichen.

Es könnte sich um einen Bufferüberlauf handeln. Was mir dazu - aber nur sehr theoretisch - einfällt:

Seit dem Patch gibt es inExtendedEventDescriptors::getTexteinen neuen Zwischenbuffer "tmpbuf".

Code: Commit - si/descriptor.c.diff

char *ExtendedEventDescriptors::getText(char *buffer, int size, const char *separation1, const char *separation2) {
+   int tmpsize = size;
+   char tmpbuf[tmpsize];
+   const char *fromCode = NULL;
    int index=0, len;
    for (int i=0;i<length;i++) {
       ExtendedEventDescriptor *d=(ExtendedEventDescriptor *)array[i];
       if (!d)
          continue;
-      d->text.getText(buffer+index, size);
-      len = strlen(buffer+index);
+      d->text.getText(tmpbuf+index, tmpsize, &fromCode);
+      len = strlen(tmpbuf+index);
       index += len;
-      size -= len;
+      tmpsize -= len;
    }
-
+   index = convertCharacterTable(tmpbuf, strlen(tmpbuf), buffer, size, fromCode);
+   size -= index;

Display More

Kann es vorkommen, dass das DescriptorGroup array[] nur NULL-Pointer enthält? Falls ja, und 'tmpbuf' ist nicht zufälligerweise 0-Terminiert, wird das nachfolgende strlen(tmpbuf) unerwartete Ergebnisse liefern (hätte aber nichts mit 32/64-bit zu tun)

Als ersten Versuch würde ich hier einmal ansetzten. Ein Patch dazu im Anhang.

LG Helmut

glotzipapa · Dec 16th 2020

Quote from HelmutB

Etwas schwierig zu sagen. ich habe derzeit auch keinen 32-Bit VDR um es zu vergleichen.

Es könnte sich um einen Bufferüberlauf handeln. Was mir dazu - aber nur sehr theoretisch - einfällt:

Seit dem Patch gibt es inExtendedEventDescriptors::getTexteinen neuen Zwischenbuffer "tmpbuf".

Als ersten Versuch würde ich hier einmal ansetzten. Ein Patch dazu im Anhang.

Danke für die schnelle Reaktion, leider kein Erfolg.

Fourty2 · Dec 16th 2020

Quote from glotzipapa

Eine vorhanden 64-Bit Installation läuft ohne den Patch problemlos. Kann sein, dass hier ein 32/64Bit Problem vorliegt? Hat jemand anderes die aktuelle git-Version erfolgreich auf einem Raspi laufen?

Habe die GIT Version auf einem RPi2 (V1.1) laufen. Schien mir soweit problemlos.

Das ist aber ein VDR-Streamdev Slave:

EPG, der epg2vdr/scraper2vdr-Cache und Channels.conf werden beim Start per rsync vom Hauptsystem gezogen (die 5k Aufnahmen brauchen ja schon 15 Min...)

Edit:

Habe allerdings Kernel 5.4.51 (meine ich) laufen, da der Aktuelle mit rpihddevice nicht vernünftig läuft (kein Bild nach umschalten - EPG ist aber da und ok)

Stefan

glotzipapa · Dec 16th 2020

Quote from Fourty2

Habe die GIT Version auf einem RPi2 (V1.1) laufen. Schien mir soweit problemlos.

Super, danke für die Info. Welche Distri verwendest du?

Jetzt wirds richtig ätzend, weil das Problem anscheinend Distri abhängig ist. Das erklärt auch warum es bisher keine Beschwerden gab. In diesem Sonnensystem bin ich wohl der einzige der seine VDR-Distri selbst baut.

Fourty2 · Dec 16th 2020

Code

login as: root
root@sara's password:
____
/ ___|  __ _ _ __ __ _
\___ \ / _` | '__/ _` |
___) | (_| | | | (_| |
|____/ \__,_|_|  \__,_|




Welcome to  Raspbian GNU/Linux 10 (buster) 5.4.51-v7+
IP:            192.168.1.8
System load:   1.05 0.35 0.12   Up time:       1 min
Memory usage:  17 % of 747MB
Usage of /:    65% of 15G

Display More

Allerdings mit eigenen VDR-Paketen und SysV Init.
Ursprünglich per unattended-net-installer installiert (o.s.ä.).

channels.conf und epg.data sind ganz ...

Stefan

kls · Dec 17th 2020

Quote from HelmutB

Kann es vorkommen, dass das DescriptorGroup array[] nur NULL-Pointer enthält?

Unabhängig von glotzipapas Problem ist diese Initialisierung auf alle Fälle sinnvoll und ich übernehme sie.

MarkusE · Dec 17th 2020

Hi,

in libsi/descriptor.c, Zeile 104:

Code

tmpsize -= len;

Könnte = 0 werden. getText schreibt dann

Code

buffer[size-1] = 0;

Also entweder in getText überprüfen, ob size > 0. Oder vor dem Aufruf von getText prüfen.

~ Markus

HelmutB · Dec 17th 2020

Auch bei mehrmaligen Betrachtung des EPG Codes fällt mir nichts Verdächtiges auf.

Um unerwartete Ergebnisse zu erkennen, habe ich einen Patch der in GetText() die Zwischenwerte von "len", "Index" und ""size" bzw. "tmpsize" ausgibt. Das sieht dann bei mir im syslog so aus:

Code

Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611] *** ExtEvent getText: s=3433
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611]     ExtEvent[0]: l=248 i=248 t=3185
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611]     ExtEvent[1]: l=248 i=496 t=2937
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611]     ExtEvent[2]: l=248 i=744 t=2689
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611]     ExtEvent[3]: l=97 i=841 t=2592
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611]     ExtEvent conv: l=841 i=841 s=2592
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611] === ExtEvent Done: i=841 s=2592  <<<-- freier Buffer
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611] *** ExtEvent getText: s=517
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611]     ExtEvent[0]: l=124 i=124 t=393
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611]     ExtEvent conv: l=124 i=124 s=393
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611] === ExtEvent Done: i=124 s=393
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611] *** ExtEvent getText: s=769
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611]     ExtEvent[0]: l=187 i=187 t=582
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611]     ExtEvent conv: l=187 i=187 s=582
Dec 17 22:03:05 gentoo64vdr vdr[7582]: [7611] === ExtEvent Done: i=187 s=582

Display More

MarkusE : in der Zeile "ExtEvent Done" sieht man, das der Buffer nie voll ausgenutzt wird, die verbleibende "size" ist sogar größer als die tatsächlich im Descriptor vorhandenen Daten. Der "Item"-Loop war bei meinem Test immer ohne Information.

glotzipapa : Falls du es testest, vielleicht erkennst du unpassende Werte (nicht zu lange laufen lassen, es wird viel ins syslog geschrieben).

LG Helmut

wirbel · Dec 18th 2020

Vielleicht eher etwas für 2.5, eine harmlose Warnung von gcc:

vdr/dvbspu.c: In Elementfunktion »bool cDvbSpuBitmap::getMinSize(const sDvbSpuPalDescr*, sDvbSpuRect&) const«:

vdr/dvbspu.c:148:50: Warnung: geschweifte Klammern um leeren Körper in einer »if«-Anweisung empfohlen [-Wempty-body]

size.x1, size.y1, size.x2, size.y2);

vdr/dvbspu.c:146+, anstelle von

if (ret)

DEBUG(...);

if (ret) {

DEBUG(...);

}

kls · Dec 18th 2020

Es gibt etliche Stellen der Form

Code

if (...)
   ;

Wieso sollte das ausgerechnet hier ein Problem sein?

wirbel · Dec 18th 2020

weil der leere Befehl nach einem if oder else kommt, warnt der compiler.

Man könnte auch einfach das DEBUG macro falls unbenutzt zu {} definieren.

PS: dito

vdr/pat.c: In Elementfunktion »bool cPatFilter::PmtVersionChanged(int, int, int, bool)«:

vdr/pat.c:398:110: Warnung: geschweifte Klammern um leeren Körper in einer »else«-Anweisung empfohlen [-Wempty-body]

DBGLOG("PMT %d %2d %5d/%d %2d -> %2d", Transponder(), i, PmtPid, Sid, se->Version(), Version);

^

vdr/pat.c: In Elementfunktion »virtual void cPatFilter::Process(u_short, u_char, const u_char*, int)«:

vdr/pat.c:431:96: Warnung: geschweifte Klammern um leeren Körper in einer »if«-Anweisung empfohlen [-Wempty-body]

DBGLOG(" PAT %d: %d sections", Transponder(), pat.getLastSectionNumber() + 1);

^

vdr/pat.c:462:68: Warnung: geschweifte Klammern um leeren Körper in einer »if«-Anweisung empfohlen [-Wempty-body]

DBGLOG(" PAT %d: shared PMT PIDs", Transponder());

^

vdr/pat.c:732:55: Warnung: geschweifte Klammern um leeren Körper in einer »if«-Anweisung empfohlen [-Wempty-body]

DBGLOG("PMT timeout Pid %d", activePmt->Pid());

kls · Dec 18th 2020

Quote from wirbel

Man könnte auch einfach das DEBUG macro falls unbenutzt zu {} definieren.

Das war auch mein erster Versuch, klappt aber nicht.

Aber

#define DEBUG(format, args...) void()

funktioniert. Kannst du bitte testen, ob damit die Warnung weg ist? Bei mir kommt die nämlich nicht. Ist das wieder was Neues?

wirbel · Dec 18th 2020

Nichts neues, nur -Wall -Wextra in meinen Flags.

void() funktioniert.

do {} while(0) würde auch gehn, nicht getestet.

Code

dvbspu.c:41
-#define DEBUG(format, args...)
+#define DEBUG(format, args...) void()

pat.c:337
-#define DBGLOG(a...)
+#define DBGLOG(a...) void()


timers.c:984
-         else // identical timer, nothing to do
-            ;
+         else {
+            // identical timer, nothing to do
+            }

Display More

Danke und Gruß

GIT-Archiv für VDR auf http://git.tvdr.de

Participate now!

Share