CodeJun 04 21:13:47 [vdr] [19956] /usr/bin/vdr cChannelsLock::cChannelsLock(bool) at channels.h:258 (discriminator 2) Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr at ??:0 Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr cDisplayChannel::DisplayInfo() at menu.c:4627 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.
./opt-42-x_MainMenuHooks-v1.0.1.patch: eOSState state = cOsdMenu::ProcessKey(Key);
./opt-50_graphtft.patch: virtual eOSState ProcessKey(eKeys Key);
./opt-50_graphtft.patch: virtual eOSState ProcessKey(eKeys Key);
./opt-65_pin.patch: eOSState state = cOsdMenu::ProcessKey(Key);
./vdr-2.3.4_zapcockpit.patch:- ProcessKey(FirstKey);
./vdr-2.3.4_zapcockpit.patch:+ ProcessKey(FirstKey);
./vdr-2.3.4_zapcockpit.patch:+eOSState cDisplayChannelExtended::ProcessKey(eKeys Key)
./vdr-2.3.4_zapcockpit.patch:+ return cDisplayChannel::ProcessKey(Key);
./vdr-2.3.4_zapcockpit.patch:+ return cDisplayChannel::ProcessKey(Key);
./vdr-2.3.4_zapcockpit.patch:+ //other keys are handled by cDisplayChannel::ProcessKeys()
./vdr-2.3.4_zapcockpit.patch:+ //other keys are handled by cDisplayChannel::ProcessKeys()
./vdr-2.3.4_zapcockpit.patch: virtual eOSState ProcessKey(eKeys Key);
./vdr-2.3.4_zapcockpit.patch:+ virtual eOSState ProcessKey(eKeys Key);
./vdr-2.3.4_zapcockpit.patch:+ Menu->ProcessKey(NORMALKEY(key));
./vdr-2.3.4_zapcockpit.patch: Interact->ProcessKey(key);
./vdr-2.3.4_zapcockpit.patch:+ Menu->ProcessKey(NORMALKEY(key));wie wäre hier das Vorgehen, am besten schaut einer drüber der sich mit C auch nur etwas besser auskennt als ich 
[/Edit]
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?
[...] Das sind alle Vorkommen von ProcessKey in debian Patches, sieht in der Tat ausschließlich nach zapcockpit Patch aus.
Dieser Patch ist bei mir gar nicht installiert.
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:
class cListBase {
...
public:
...
bool Lock(cStateKey &StateKey, bool Write = false, int TimeoutMs = 0) const;
...
///< To implicitly avoid deadlocks when locking more than one of the global
///< lists of VDR at the same time, make sure you always lock Timers, Channels,
///< 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
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
Die Listen sind über die Namen durchnummeriert, worüber sich die Reihenfolge ergibt:
1 Timers
2 Channels
3 Recordings
4 DelRecs
5 Schedules
Klaus
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
Nein, war mein Fehler bei der Interpretation
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
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
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
