Man könnte doch sicherlich dafür sorgen, dass wenn von "Gerät 1" ein Eingabe Event kommt, dann die Eingabe für x Millisekunden die Eingabe für alle Andern gesperrt ist, oder?
Ich glaube, das Problem kann man ignorieren. In der Regel wird man nicht simultan über zwei Kanäle Eingaben machen und selbst wenn sich mal zwei Personen in die Quere kommen werden das die Betroffenen recht schnell merken, wenn sich das Menü "einfach so" ändert 
Ich hatte jetzt an 2 verschiedenen Tagen zur jeweils gleichen Minute einen Segfault auf meinem Wiedergabe-VDR. Der Segfault trat ein beim Betrachten von live-TV, zu einem Zeitpunkt, an dem am VDR-Server eine Aufnahme startete. /video ist per nfs auf beiden Rechner gemounted.
Jun 18 19:58:07 vdr vdr[273]: [501] video directory scanner thread started (pid=273, tid=501, prio=low)
Jun 18 19:58:07 vdr kernel: video directory[501]: segfault at 82abc14 ip 08178f61 sp b13be190 error 6 in vdr[8048000+1ba000]
[...]
Jun 20 19:58:23 vdr vdr[259]: [460] video directory scanner thread started (pid=259, tid=460, prio=low)
Jun 20 19:58:23 vdr kernel: video directory[460]: segfault at 82abbdc ip 08178f61 sp 8ec46190 error 6 in vdr[8048000+1ba000]19:58 startet der Tagesschau-Timer.
18.06.:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Core was generated by `/usr/local/bin/vdr'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x08178f61 in cStateLockLog::Check (this=0x826bba0 <StateLockLog>, Name=0x81a0871 "3 Recordings", Lock=true,
Write=false) at thread.c:668
668 logThreadIds[logIndex] = ThreadId;
[Current thread is 1 (Thread 0xb13beb40 (LWP 501))]
(gdb) bt
#0 0x08178f61 in cStateLockLog::Check (this=0x826bba0 <StateLockLog>, Name=0x81a0871 "3 Recordings", Lock=true, Write=false) at thread.c:668
#1 0x08179401 in cStateLock::Lock (this=0x82645d0 <cRecordings::recordings+16>, StateKey=..., Write=false, TimeoutMs=0) at thread.c:711
#2 0x08185293 in cListBase::Lock (this=0x82645c0 <cRecordings::recordings>, StateKey=..., Write=false, TimeoutMs=0) at tools.c:2123
#3 0x08142cfd in cVideoDirectoryScannerThread::Action (this=0x8fdabc8) at recording.c:1389
#4 0x08176e44 in cThread::StartThread (Thread=0x8fdabc8) at thread.c:293
#5 0xb76c2271 in start_thread () from /lib/libpthread.so.0
#6 0xb71d11be in clone () from /lib/libc.so.6
(gdb)20.06.:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Core was generated by `/usr/local/bin/vdr'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x08178f61 in cStateLockLog::Check (this=0x826bba0 <StateLockLog>, Name=0x81a0871 "3 Recordings", Lock=true,
Write=false) at thread.c:668
668 logThreadIds[logIndex] = ThreadId;
[Current thread is 1 (Thread 0x8ec46b40 (LWP 460))]
(gdb) bt
#0 0x08178f61 in cStateLockLog::Check (this=0x826bba0 <StateLockLog>, Name=0x81a0871 "3 Recordings", Lock=true, Write=false) at thread.c:668
#1 0x08179401 in cStateLock::Lock (this=0x82645d0 <cRecordings::recordings+16>, StateKey=..., Write=false, TimeoutMs=0) at thread.c:711
#2 0x08185293 in cListBase::Lock (this=0x82645c0 <cRecordings::recordings>, StateKey=..., Write=false, TimeoutMs=0) at tools.c:2123
#3 0x08142cfd in cVideoDirectoryScannerThread::Action (this=0xa2393a8) at recording.c:1389
#4 0x08176e44 in cThread::StartThread (Thread=0xa2393a8) at thread.c:293
#5 0xb76d3271 in start_thread () from /lib/libpthread.so.0
#6 0xb71e21be in clone () from /lib/libc.so.6
(gdb) quitDas sieht sich mehr als nur ein wenig ähnlich, finde ich.
Was kann ich noch an Infos melden?
Christian
Ist das der einzige Timer, oder gibt es andere, die funktionieren?
Fährt der Rechner für diesen Timer hoch, oder läuft er zu dem Zeitpunkt bereits längere Zeit?
Kannst du im core-File schauen, welchen Wert logIndex zu dem Zeitpunkt hat?
Klaus
Hallo Klaus,
Im core vom 18.06.:
(gdb) print logIndex
$1 = 65536
und vom 20.06.:
(gdb) print logIndex
$1 = 65550
Der Server läuft durch, lediglich vdr lasse ich dort morgens gegen 4 Uhr neu starten. Der Client lief heute >30 Minuten bis zum Crash, am 18. bestimmt auch. Die Aufnahmen werden auf dem Server durchgeführt, der Client selbst hat keinerlei Timer programmiert.
Für andere Timer ist mir das Verhalten bisher nie bewusst untergekommen.
vdr64 ~ # grep Tagess /etc/vdr/etc/timers.conf
1:S19.2E-1-1019-10301:MTWTFSS:1958:2018:50:99:Tagesschau:<epgd><timerid>33</timerid></epgd>Christian
Ich kann mir beim besten Willen nicht vorstellen, wie logIndex auf solche Werte kommen kann.
Bau doch bitte mal folgende Testausgaben ein und melde dich wieder, wenn sie erzeugt werden:
--- thread.c 2017-06-09 10:27:22.000000000 +0200
+++ thread.c 2017-06-21 10:52:57.501776484 +0200
@@ -643,6 +643,11 @@
if (0 <= n && n < SLL_MAX_LIST) {
int b = 1 << n;
cMutexLock MutexLock(&mutex);
+ if (logIndex >= SLL_SIZE) {
+ dsyslog("----- invalid logIndex: logIndex");
+ logIndex = 0;
+ cBackTrace::BackTrace();
+ }
tThreadId ThreadId = cThread::ThreadId();
int Index = threadIds.IndexOf(ThreadId);
if (Index < 0) {
@@ -676,6 +681,11 @@
Dump(Name, ThreadId);
dumped = true;
}
+ if (logIndex >= SLL_SIZE) {
+ dsyslog("----- invalid logIndex: logIndex");
+ logIndex = 0;
+ cBackTrace::BackTrace();
+ }
}
}
}
Klaus
Ich sehe da auch nicht viele Möglichkeiten, evtl. wenn ein Index aus dem Ruder läuft und bei der Veränderung von logCounter in der Check-Funktion über das Array hinaus gegriffen wird? Wie auch immer das passieren könnte...
Lars.
Ich glaub das Problem hatte ich auch bereit mehrfach 
Core was generated by `/usr/local/src/VDR/vdr'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055d068bb970b in cStateLockLog::Check (this=0x55d068eae4c0 <StateLockLog>, Name=0x55d068befaac "3 Recordings", Lock=true, Write=false) at thread.c:668
668 logThreadIds[logIndex] = ThreadId;
[Current thread is 1 (Thread 0x7fc98948f700 (LWP 914))]
(gdb)
(gdb) bt
#0 0x000055d068bb970b in cStateLockLog::Check(char const*, bool, bool) (this=0x55d068eae4c0 <StateLockLog>, Name=0x55d068befaac "3 Recordings", Lock=true, Write=false) at thread.c:668
#1 0x000055d068bb996b in cStateLock::Lock(cStateKey&, bool, int) (this=0x55d068ea6160 <cRecordings::recordings+32>, StateKey=..., Write=false, TimeoutMs=0) at thread.c:711
#2 0x000055d068bc85b7 in cListBase::Lock(cStateKey&, bool, int) const (this=0x55d068ea6140 <cRecordings::recordings>, StateKey=..., Write=false, TimeoutMs=0) at tools.c:2123
#3 0x000055d068ad9eac in cRecordings::GetRecordingsRead(cStateKey&, int) (StateKey=..., TimeoutMs=0) at recording.h:236
#4 0x00007fc9eef8ddd4 in cRecordingsFolderInfo::Get(char const*) (this=0x7fc9ef2be660 <recFolderInfo>, Folder=0x7fc98948eaf0 "mareTV") at extensions/recfolderinfo.c:110
#5 0x00007fc9ef040f1f in cCeMenuRecordings::Parse(bool) (this=0x55d06b3d28a0, forced=true) at coreengine/listelements.c:1948
#6 0x00007fc9eefe837f in cViewElement::ParseDetached() (this=0x55d06b3d28a0) at coreengine/viewelement.c:409
#7 0x00007fc9eefa0f64 in cDetacher::Action() (this=0x55d06f7b9a00) at coreengine/animation.c:48
#8 0x000055d068bb7e78 in cThread::StartThread(cThread*) (Thread=0x55d06f7b9a00) at thread.c:293
#9 0x00007fc9fd417297 in start_thread () at /usr/lib/libpthread.so.0
#10 0x00007fc9fbd8b25f in clone () at /usr/lib/libc.so.6
(gdb) print logIndex
$1 = 65536
(gdb)
Ich bilde mir ein, dass es nicht mehr auftritt, seitdem ich den Skin von skindesigner auf VDR-Native gewechselt habe, aber sicher bin ich mir nicht.
Peter
seitdem ich den Skin von skindesigner auf VDR-Native gewechselt habe
Käme nicht überraschend, da bekannt ist, dass "vdr-plugin-skindesigner" Anpassung bzgl. dem Locking im VDR benötigen würde ...
- skindesigner - bad locking order for vdr-2.3.x
- [ANNOUNCE] VDR developer version 2.3.6
Gruß
Frank
Käme nicht überraschend, da bekannt ist, dass "vdr-plugin-skindesigner" Anpassung bzgl. dem Locking im VDR benötigen würde ...
Also mein Verständnis dieser "Locking-Nummer" ist wie folgt:
In die neueren VDR-Versionen wurde ein Mechanismus eingebaut, um falsche Locking-Sequenzen erkennen zu können.
Diese falschen Locking-Sequenzen können potentiell zu mehr oder weniger zufälligen, schlecht erkennbaren Abstürzen führen.
Aber: Mein VDR ist bisher mit skindesigner (so gut wie nie abgestürzt und jetzt in den letzten Tagen mehrfach, ohne dass sich an der codebase von skindesigner was geändert hat.
Gibt es hier nicht eher einen Überlauf in dem neuen VDR-Mechanismus, der falsche Locking-Sequenzen erkennen soll?
Ich hab genau die gleichen Probleme mit skindesigner und 2.3.7 und stell mir die gleiche Frage warum plötzlich so große Probleme auftreten wenn der vdr das nur aufzeigt mit den locking Problemen und sich am Plugin selbst seit Monaten nichts geändert hat...
Christian
Ich sehe halt einfach nicht, wie und wo logIndex diese seltsamen Werte annehmen kann. Ich stehe da vor einem vollkommenen Rätsel!
Wenn das für jemanden ein großes Problem ist, dann kann er auch in thread.c die Zeile
#define DEBUG_LOCKSEQ
auskommentieren. Dann werden halt die Lock-Sequenzen nicht mehr geprüft.
Klaus
Nur mal ein Schnellschuss: Kann nicht in logCounter der Index um einen zu gross werden?
TomJoad: ich glaube, da hast du den Finger in die Wunde gelegt!
Womöglich laufen mit skindesigner ein paar mehr Threads, und dann langt logCounter in das unmittelbar dahinter liegende logIndex rein (DEBUG_LOCKCALL ist ja standardmäßig nicht definiert). Bei genauerer Überlegung ist es natürlich Quatsch, daß logCounter ein festes Array ist, denn den Counter muß es ja pro Thread geben. Das muß ich nochmal etwas umgestalten.#
Aber zumindest ist jetzt mal klar, wie es zu diesem Fehler kommen konnte. Well spotted!
Ich schlage vor, bis zu einer Lösung einfach DEBUG_LOCKSEQ auszuschalten.
Klaus
Genau das meinte ich.
Lars
Weiß nicht, ob das weiter hilft:
(gdb) print logCounter
$1 = {"\000\000\000\000\000\000\000\000" <repeats 20 times>}
(gdb) set print repeats unlimited
(gdb) print logCounter
$2 = {"\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000",
"\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000",
"\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000",
"\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000",
"\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000",
"\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000",
"\000\000\000\000\000\000\000\000", "\000\000\000\000\000\000\000\000"}
(gdb)Weiß nicht, ob das weiter hilft:
Wie die Struktur aussieht weiß ich, nur ist sie halt eigentlich falsch.
Saublöder Fehler von mir...
Nur gut, daß das jetzt tatsächlich aufgetreten ist und nicht erst in der nächsten Stable... ;-).
Klaus
Ich glaub das Problem hatte ich auch bereit mehrfach
Sieht aus wie meiner von grad eben:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Core was generated by `/usr/local/bin/vdr'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x08178f0c in cStateLockLog::Check (this=0x826bba0 <StateLockLog>, Name=0x81a08b1 "3 Recordings", Lock=true, Write=false) at thread.c:673
673 logThreadIds[logIndex] = ThreadId;
[Current thread is 1 (Thread 0x8c0fbb40 (LWP 555))]
(gdb) bt
#0 0x08178f0c in cStateLockLog::Check (this=0x826bba0 <StateLockLog>, Name=0x81a08b1 "3 Recordings", Lock=true, Write=false) at thread.c:673
#1 0x08179431 in cStateLock::Lock (this=0x82645d0 <cRecordings::recordings+16>, StateKey=..., Write=false, TimeoutMs=0) at thread.c:721
#2 0x081852c3 in cListBase::Lock (this=0x82645c0 <cRecordings::recordings>, StateKey=..., Write=false, TimeoutMs=0) at tools.c:2123
#3 0xb69e2690 in cRecordings::GetRecordingsRead (TimeoutMs=0, StateKey=...) at /usr/local/src/vdr-2.3.7/include/vdr/recording.h:236
#4 cRecordingsFolderInfo::Get (this=0xb6ab8bc0 <recFolderInfo>, Folder=0x8c0fb0b8 "Tagesschau") at extensions/recfolderinfo.c:110
#5 0xb6a65552 in cCeMenuRecordings::Parse (this=0xa30baf0, forced=true) at coreengine/listelements.c:1948
#6 0xb6a237bf in cViewElement::ParseDetached (this=0xa30baf0) at coreengine/viewelement.c:409
#7 0xb69f3a82 in cDetacher::Action (this=0xe403c68) at coreengine/animation.c:48
#8 0x08176dc4 in cThread::StartThread (Thread=0xe403c68) at thread.c:293
#9 0xb7671271 in start_thread () from /lib/libpthread.so.0
#10 0xb71801be in clone () from /lib/libc.so.6
(gdb) print logIndex
$1 = 65538Die Testausgabe von Klaus ('invalid logIndex: logIndex') hat dabei nicht ausgelöst.
Der Crash kam nicht bei live-TV, sondern beim Navigieren durch das recordings-menu beim Ordnerwechsel in 'Tagesschau'.
Christian
Ich hoffe, daß das Problem mit beiliegendem Patch behoben ist.
Ich habe darin zwei Dinge gefixt. Zum einen werden jetzt die Thread-Einträge in threadIds und flags wiederverwendet, womit die Liste immer nur so viele Einträge hat, wie gleichzeitig Threads einen Lock halten (und nicht mehr beliebig groß wird). Und die Größe von logCounter ist separat definiert und wird überwacht (wobei die niemals überschritten werden sollte, und wenn, dann setzen wir halt SLL_THREADS höher).
Klaus
Kann man evtl drüber nachdenken vllt ein "zwischenstable" vdr zu releasen sobald die aktuellen Themen mit MTD und der lock order ausgestanden sind.
Es ist halt so das man wegen MTD an einigen Stellen auf dev rumwerkelt und nie weiß ob die Kiste nach dem nächsten Update nicht mehr Probleme hat als vorher, zurück auf stable geht aber nicht weil dann das CAM nicht wie geünscht arbeitet. Wäre vllt auch auch für die Pluginentwickler schön nicht mit so vielen 'ifdefs' arbeiten zu müssen.
Ansonsten würde ich mir in einem separaten ppa einen gut funktionierenden Stand einfrieren wollen.
Christian
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!