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

seahawk1986 · December 15, 2020 at 1:08 PM

Quote from kls

Bitte ausgiebig testen.

Wer das mit Ubuntu 20.04 machen will: in https://launchpad.net/~seahawk1986-h…r-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 · December 15, 2020 at 2:27 PM

Quote from seahawk1986

Wer das mit Ubuntu 20.04 machen will: in https://launchpad.net/~seahawk1986-h…r-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 · December 15, 2020 at 3:21 PM

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

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

--error = dlerror();

kls · December 16, 2020 at 10:19 AM

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 · December 16, 2020 at 10:55 AM

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 · December 16, 2020 at 11:01 AM

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 · December 16, 2020 at 12:53 PM

wirbel noch besser!

HelmutB † · December 16, 2020 at 9:37 PM

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 · December 16, 2020 at 10:08 PM

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 · December 16, 2020 at 10:24 PM

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 · December 16, 2020 at 10:30 PM

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 · December 16, 2020 at 10:43 PM

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 · December 17, 2020 at 1:56 PM

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 · December 17, 2020 at 4:19 PM

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 † · December 17, 2020 at 11:08 PM

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 · December 18, 2020 at 11:30 AM

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 · December 18, 2020 at 11:46 AM

Es gibt etliche Stellen der Form

Code

if (...)
   ;

Wieso sollte das ausgerechnet hier ein Problem sein?

wirbel · December 18, 2020 at 12:26 PM

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 · December 18, 2020 at 1:14 PM

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 · December 18, 2020 at 3:24 PM

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!

Users Viewing This Thread