[ANNOUNCE] VDR developer version 2.3.6

  • Ok, danke.


    Zu dieser Locking-Tabelle im syslog, muß man da jetzt was beachten, muß was behoben werden oder müssen wir einfach mit ein paar Zeile mehr an Log-Output leben?


    Hab grad gesehen, wenn ich skindesigner deaktiviere, kommt diese Art Output beständig für epgsearch ...


    Gruß
    Frank

    HowTo: APT pinning

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von fnu ()

  • Code
    1. Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr cChannelsLock::cChannelsLock(bool) at channels.h:258 (discriminator 2)
    2. Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr at ??:0
    3. Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr cDisplayChannel::DisplayInfo() at menu.c:4627
    4. Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr cDisplayChannel::cDisplayChannel(int, bool) at menu.c:4581


    Kann es sein, daß du menu.c gepatcht hast? Im original Code ist Zeile menu.c:4627 in cDisplayChannel::ProcessKey() und nicht in cDisplayChannel::DisplayInfo().


    Klaus


    ich würde sagen da gibt es nicht nur eine Stelle von, die kommen uA aus dem zapcockpit Patch.


    Ich hab die Meldungen auch, Funktionion ist aber da wie ich das sehe, abstürzen tut auch nichts.


    Denke der ein oder andere Patch wird überarbeitet werden müssen...


    Christian



    [Edit]
    Das sind alle Vorkommen von ProcessKey in debian Patches, sieht in der Tat ausschließlich nach zapcockpit Patch aus.



    wie wäre hier das Vorgehen, am besten schaut einer drüber der sich mit C auch nur etwas besser auskennt als ich ;D


    [/Edit]

     CKone: yavdr-ansible/18.04 LTS/2.3.8/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.3.8/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.3.8 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD Red WD30EFRX 3TB in SW Raid5

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von CKone ()

  • Mir ist aufgefallen, dass der VDR immer mal wieder seine Sprachen nicht findet:



    Starte ich den VDR neu, dann ist (meistens) alles wieder da:



    Woran kann das liegen?


  • Zu dieser Locking-Tabelle im syslog, muß man da jetzt was beachten, muß was behoben werden oder müssen wir einfach mit ein paar Zeile mehr an Log-Output leben?


    Die Ausgaben dienen dazu, mögliche Deadlocks frühzeitig zu erkennen (und zu beheben). Im Idealfall sollten die Meldungen niemals kommen.

    Zitat


    Hab grad gesehen, wenn ich skindesigner deaktiviere, kommt diese Art Output beständig für epgsearch ...


    Dann werden dort die Locks nicht in der vorgesehenen Reihenfolge gesetzt.


    Zum Verständnis:


    Wenn von zwei Threads 1 und 2 jeder die Locks A und B setzen will, und Thread 1 setzt erst Lock A und dann Lock B, während Thread 2 erst B und dann A setzt, so kann das sehr lange gut gehen. Sobald aber die Zeitscheiben so vergeben werden, daß Thread 1 zwar Lock A setzen kann, aber dann sofort Thread 2 drankommt und Lock B setzt, und gleich wieder Thread A drankommt und auf Lock B wartet, und schließlich Thread 2 dann auf Lock A wartet, dann haben wir einen klassischen Deadlock, der sich ohne Timeout nicht mehr von selber auflöst und schließlich zum Abbruch durch den Watchdog (sofern aktiviert) führt.


    Wenn beide Threads die Locks dagegen immer in der gleichen Reihenfolge (erst A dann B) ausführen, dann ist garantiert, daß es zu keinem Deadlock kommen kann.


    Man muß übrigens bei mehreren Locks nicht immer *alle* locken, wenn man nur einige braucht. Wenn man bei z.B. 4 Locks A, B, C und D nur B und D braucht, dann reicht es, auch nur diese zu locken. Man muß nicht auch noch A und C locken. Wichtig ist nur die Reihenfolge (in diesem Beispiel "alphabetisch").


    Klaus

  • wie wäre hier das Vorgehen


    Die Locks müssen in der richtigen Reihenfolge ausgeführt werden:

    Code
    1. class cListBase {
    2. ...
    3. public:
    4. ...
    5. bool Lock(cStateKey &StateKey, bool Write = false, int TimeoutMs = 0) const;
    6. ...
    7. ///< To implicitly avoid deadlocks when locking more than one of the global
    8. ///< lists of VDR at the same time, make sure you always lock Timers, Channels,
    9. ///< Recordings and Schedules in this sequence.


    Klaus

  • Mir ist aufgefallen, dass der VDR immer mal wieder seine Sprachen nicht findet:
    ...
    Woran kann das liegen?


    Kann ich mir auch nicht erklären.
    Bau doch mal in I18nInitialize() (in i18n.c) ein paar Ausgaben ein, um zu sehen, was da jeweils abläuft.


    Klaus

  • Wichtig ist nur die Reihenfolge (in diesem Beispiel "alphabetisch").

    Vielen Dank für die ausführliche Erklärung.


    Um Deine alphabetische Analogie zu verwenden, wäre dann Timers=A, Channels=B, Recordings=C und Schedules=D, richtig?


    Gruß
    Frank

    HowTo: APT pinning

  • Um Deine alphabetische Analogie zu verwenden, wäre dann Timers=A, Channels=B, Recordings=C und Schedules=D, richtig?


    Richtig. Wobei es bei "Recordings" auch noch die "Deleted Recordings" gibt, aber das ist nur eine Feinheit.


    Klaus

  • Wobei es bei "Recordings" auch noch die "Deleted Recordings" gibt

    Diese Feinheit wäre dann auch "C", oder wo in der Sequenz?


    Gruß
    Frank

    HowTo: APT pinning

  • Danke.


    Gruß
    Frank

    HowTo: APT pinning

  • Bzgl. STL in VDR und Plugins geht es hier bitte weiter: Grundsatzdiskussion Funktionen aus STL in VDR bzw. Plugins


    Regards
    fnu

    HowTo: APT pinning

  • kls


    Es ist doch explizit erlaubt worden, dass ein Thread sich den gleichen Lock mehrfach holt. Warum wird das jetzt als Lock-Sequenz-Fehler ausgegeben?
    Ich hatte gerade den Code aufgeräumt und das ständige Weitergeben von Pointern rausgenommen, weil es völlig unübersichtlich war.

    vdr-2.3.8
    softhddevice, chanman, dbus2vdr, dvd, dvdswitch, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, tvguide, vdrmanager, vnsiserver

    linux-3.13.0-129 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Der gleiche Thread darf sich auch weiterhin den gleichen Lock mehrfach holen. Das sollte eigentlich durch


    if ((flags[Index] & ~b) < b) // thread holds only "smaller" locks -> OK


    abgedeckt sein. Oder hast du eine konkrete Beobachtung gemacht, die dem widerspricht?


    Klaus

  • Hm. Mein Studium ist nun etwas her und ich arbeite die meiste Zeit fachfremd seitdem.


    Rein intuitiv würde ich daran zweifeln, dass eine Reihenfolge beim Einholen von Locks Deadlocks verhindern kann.


    Gibt es nicht ein API, das mehrere locks gleichzeitig holt? Das sollte einiges verbessern. Hilft dennoch nicht weiter, wenn man später im Algorithmus feststellt, dass man noch weitere locks benötigt.


    Ob das nun besser hier im Thread oder im Zweig mit der stl aufgehoben ist, kann ich mich gerade nicht entscheiden.


    Schönen Gruß,
    Christoph

    Reelbox Avantgarde II, 2GB, Turion X2 (TL-66), Kingston SSD (64GB)
    BM2LTS 2.95.1 RC10
    QNAP TS 412

  • Nein, war mein Fehler bei der Interpretation

    vdr-2.3.8
    softhddevice, chanman, dbus2vdr, dvd, dvdswitch, dynamite, epgsearch, femon, filebrowser, graphlcd, graphtftng,
    menuorg, osdteletext, radio, recsearch, streamdev-server, tvguide, vdrmanager, vnsiserver

    linux-3.13.0-129 M3N78-VM (Nvidia 8200) CIne CT-V7 DVB-C
    yavdr-0.6 als Basis mit vielen Änderungen

  • Rein intuitiv würde ich daran zweifeln, dass eine Reihenfolge beim Einholen von Locks Deadlocks verhindern kann.


    Doch tut es ;-).


    Klaus

  • Hm. Mein Studium ist nun etwas her und ich arbeite die meiste Zeit fachfremd seitdem.


    Ich habe es gar nicht erst studiert, bin quer eingestiegen und mache es jetzt seit mehr als 30 Jahren.


    Rein intuitiv würde ich daran zweifeln, dass eine Reihenfolge beim Einholen von Locks Deadlocks verhindern kann.


    Die Reihenfolge ist ja gerade das Problem. Hier habe ich das mal in einem anderen Zusammenhang erklärt.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Der gleiche Thread darf sich auch weiterhin den gleichen Lock mehrfach holen.


    Das stimmt zwar, aber anscheinend passiert da bei der Auswertung noch ein Fehler. Wenn ein Thread einen Lock innerhalb des gleichen Locks nochmal setzt, dann wird bei der Freigabe des "inneren" Locks bereits das entsprechende Flag in cStateLockLog zurückgesetzt. Dadurch kann es zu "false positive" Meldungen kommen. Muß ich wohl mit einem Zähler statt mit Bits machen.


    Ich arbeite dran...


    Klaus