QuoteDisplay MoreVDR developer version 2.3.6 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.6.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.5-2.3.6.diff
MD5 checksums:
eab982df03da492a7d263718a8c487c2 vdr-2.3.6.tar.bz2
84a53afa495740bfdf9aab4b8900df99 vdr-2.3.5-2.3.6.diff
WARNING:
========
This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging.
The changes since version 2.3.5:
- Added backtrace functions for debugging (see cBackTrace in thread.h).
- Added checking the correct sequence of locking global lists (with help and
suggestions from Jasmin Jessich). At the first occurrence of an invalid locking
sequence, the 20 most recent locks will be written to the log file, followed by a
backtrace that led to the call in question. This code can be activated by defining
the macro DEBUG_LOCKSEQ in thread.c (which is on by default).
When debugging an actual invalid locking sequence, you can additionally define
the macro DEBUG_LOCKCALL in thread.c, which will add information about the caller
of each lock. Note that this may cause some stress on the CPU, therefore it is off
by default.- The file Make.config.template now reacts on DEBUG=1 in the 'make' command line,
and disables code optimizations by setting -O0 (thanks to Jasmin Jessich).
This can be helpful when backtracing highly optimized code. You may want to
'make distclean' before running 'make' with a modified setting of DEBUG, to make
sure all object files are newly compiled.- Fixed the locking sequence when dumping EPG data.
- Fixed the locking sequence when starting a recording.
- The Makefiles now use the macro $(Q) instead of a plain '@' in front of their
commands, so that verbosity can be controlled by the user (suggested by Jasmin
Jessich). Add VERBOSE=1 to the 'make' call in the VDR source directory to see the
actual commands that are executed.
Plugin authors should modify their makefiles accordingly, by simply preceeding
the respective commands with '$(Q)' and inserting '@echo XX $@' (where XX is one
of the character combinations listed in the release note for version 2.3.5) before
the command.
The newplugin script has also been modified accordingly.
Note that if you build a plugin directly in the plugin's own source directory,
the $(Q) macro won't be defined and commands will be displayed. You can add
Q=@ to the make call to have it less verbose (provided the plugin's Makefile
was modified as described above).- Added clearing CiResourceHandlers before shutting down the plugin manager.
- Fixed a double channel switch when pressing the Channel+/- keys while no menu
or channel display is open.- Fixed generating k_Release key events for LIRC remote controls (due to the short
timeout another normal key was sometimes put into the queue after the generated
release). Also removed some code redundancy and added some buffer checks.- Now using a separate mutex to fix the race between SVDRP CHAN and
cDevice::HasProgramme(), because the previous fix caused a deadlock (reported by
Derek Kelly).- Fixed a possible crash in case the SVDRP connection to a peer VDR is terminated
while getting remote timers.- Fixed the locking sequence when creating a new timer from the Schedules menu.
- Fixed the locking sequence when switching between 'Now', 'Next' and 'Schedule'
in the Schedules menu.Have fun!
Klaus
[ANNOUNCE] VDR developer version 2.3.6
-
-
Hallo Klaus,
vielen Dank für die neue Version.
Regards
Frank -
Hi,
da geht man einmal ein Stündchen aus dem Haus und schon gibt es eine neue VDR Version
Danke Klaus für die neue Version. -
Hi,
da geht man einmal ein Stündchen aus dem Haus und schon gibt es eine neue VDR Version ...
Ja, und das obwohl Klaus RCS und nicht git verwendet.
-
--obwohl
++weil>> Added checking the correct sequence of locking global lists
Das wird helfen, versteckte Probleme in Plugins zu finden, sher schön. -
Klaus, thank you for the continue support & development of VDR! It's starting to feel like `VDR reboot` after our dry spell.
-
Quote
[...] Add VERBOSE=1 to the 'make' call in the VDR source directory to see the
actual commands that are executed.
...Also wenn ich " make VERBOSE=1" aufrufe, dann wird es auch nicht "verboser", oder verstehe ich das falsch?
-
Code
> rm tools.o > make vdr CC tools.o LD vdr > rm tools.o > make VERBOSE=1 vdr CC tools.o g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -m32 -fPIC -c -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DREMOTE_KBD -DLIRC_DEVICE="/var/run/lirc/lircd" -DVIDEODIR="/video" -DCONFDIR="/video" -DARGSDIR="/video/conf.d" -DCACHEDIR="/video" -DRESDIR="/video" -DPLUGINDIR="/home/kls/vdr/VDR/PLUGINS/lib" -DLOCDIR="/home/kls/vdr/VDR/locale" -I/usr/include/freetype2 -I/home/kls/vdr/DVB/current/media_build_experimental/linux/include/uapi -o tools.o tools.c LD vdr g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -m32 -fPIC -rdynamic args.o audio.o channels.o ci.o config.o cutter.o device.o diseqc.o dvbdevice.o dvbci.o dvbplayer.o dvbspu.o dvbsubtitle.o eit.o eitscan.o epg.o filter.o font.o i18n.o interface.o keys.o lirc.o menu.o menuitems.o mtd.o nit.o osdbase.o osd.o pat.o player.o plugin.o positioner.o receiver.o recorder.o recording.o remote.o remux.o ringbuffer.o sdt.o sections.o shutdown.o skinclassic.o skinlcars.o skins.o skinsttng.o sourceparams.o sources.o spu.o status.o svdrp.o themes.o thread.o timers.o tools.o transfer.o vdr.o videodir.o -ljpeg -lpthread -ldl -lcap -lrt -lfontconfig -lfreetype /home/kls/vdr/VDR/libsi/libsi.a -o vdr
Klaus
-
OK, passt.
Ich habe es mal in die Make.config eintragen, da funktioniert es auch.
-
Ich habe mit vdr-2.3.6, beim Start Meldungen, wie folgende im Syslog:
Code
Display MoreJun 04 19:48:09 [vdr] [21090] --- begin invalid lock sequence report Jun 04 19:48:09 [vdr] [21090] 21090 - R - - - - - - - - L Jun 04 19:48:09 [vdr] [21090] 21090 - - - - - - - - - - U Jun 04 19:48:09 [vdr] [21090] 21090 - R - - - - - - - - L Jun 04 19:48:09 [vdr] [21090] 21090 - - - - - - - - - - U Jun 04 19:48:09 [vdr] [21090] 21090 - R - - - - - - - - L Jun 04 19:48:09 [vdr] [21090] 21090 - * - - - - - - - - U Jun 04 19:48:09 [vdr] [21090] 21090 - - - - - - - - - - U Jun 04 19:48:09 [vdr] [21090] 21090 - R - - - - - - - - L Jun 04 19:48:09 [vdr] [21090] 21090 - * - - - - - - - - U Jun 04 19:48:09 [vdr] [21090] 21090 - - - - - - - - - - U - Last output repeated twice - Jun 04 19:48:09 [vdr] [21090] 21090 - R - - - - - - - - L Jun 04 19:48:09 [vdr] [21090] 21090 - - - - - - - - - - U - Last output repeated twice - Jun 04 19:48:09 [vdr] [21090] 21090 R - - - - - - - - - L Jun 04 19:48:09 [vdr] [21090] 21090 - - - - - - - - - - U Jun 04 19:48:09 [vdr] [21090] 21090 - R - - - - - - - - L Jun 04 19:48:09 [vdr] [21090] 21090 - - - - - - - - - - U Jun 04 19:48:09 [vdr] [21090] 21090 - R - - - - - - - - L Jun 04 19:48:09 [vdr] [21090] 21090 R * - - - - - - - - L Jun 04 19:48:09 [vdr] [21090] 21090 invalid lock sequence: 1 Timers Jun 04 19:48:09 [vdr] [21090] full backtrace: Jun 04 19:48:10 [vdr] [21090] /usr/bin/vdr cStateLock::Lock(cStateKey&, bool, int) at thread.c:702 Jun 04 19:48:10 [vdr] [21090] /usr/bin/vdr cListBase::Lock(cStateKey&, bool, int) const at tools.c:2123 Jun 04 19:48:10 [vdr] [21090] /usr/bin/vdr cTimers::GetTimersRead(cStateKey&, int) at timers.c:822 Jun 04 19:48:10 [vdr] [21090] /usr/bin/vdr cTimersLock::cTimersLock(bool) at timers.h:221 (discriminator 2) Jun 04 19:48:10 [vdr] [21090] /usr/lib/vdr/plugins/libvdr-skindesigner.so.2.3.6 cGlobalTimers::SetLocalTimers() at globaltimers.c:82 Jun 04 19:48:10 [vdr] [21090] /usr/lib/vdr/plugins/libvdr-skindesigner.so.2.3.6 cGlobalTimers::LoadTimers() at globaltimers.c:36 Jun 04 19:48:10 [vdr] [21090] /usr/lib/vdr/plugins/libvdr-skindesigner.so.2.3.6 cViewChannel::SetChannel(cChannel const*, int) at viewdisplaychannel.c:213 Jun 04 19:48:10 [vdr] [21090] /usr/lib/vdr/plugins/libvdr-skindesigner.so.2.3.6 cSDDisplayChannel::SetChannel(cChannel const*, int) at displaychannel.c:17 Jun 04 19:48:10 [vdr] [21090] /usr/bin/vdr cDisplayChannel::DisplayChannel() at menu.c:4614 Jun 04 19:48:10 [vdr] [21090] /usr/bin/vdr cDisplayChannel::cDisplayChannel(int, bool) at menu.c:4580 Jun 04 19:48:10 [vdr] [21090] /usr/bin/vdr main at vdr.c:1070 (discriminator 3) Jun 04 19:48:10 [vdr] [21090] /lib64/libc.so.6 __libc_start_main at ??:? Jun 04 19:48:10 [vdr] [21090] /usr/bin/vdr _start at ??:? Jun 04 19:48:10 [vdr] [21090] --- end invalid lock sequence report
Aber skindesiger scheint zu funktionieren.
Muss ich mir Sorgen machen?
-
Muss ich mir Sorgen machen?Das zeigt nur an, daß da die Reihenfolge der Locks nicht so ist, daß ein Deadlock ausgeschlossen ist.
Das kann lange Zeit gut gehen, aber wenn irgendwann mal ein anderer Thread erst die Timer und dann die Channels lockt, dann könnte es passieren, daß die beiden sich gegenseitig blockieren. Daher sollten die Listen immer in der vorgegebenen Reihenfolge gelockt werden.Klaus
-
Ist das beabsichtigt, dass das mit den Locks immer nur bei einem Plugin angezeigt wird?
Je nachdem, in welcher Reihenfolge ich die Plugins labe, kommt die o.g. Meldung von einem anderen Plugin.
-
Ist das beabsichtigt, dass das mit den Locks immer nur bei einem Plugin angezeigt wird?
Jenachdem, in welcher Reihenfolge ich die Plugins labe, kommt die o.g. Meldung von einem anderen Plugin.
Es wird nur das erste Auftreten einer ungültigen Lock-Reihenfolge angezeigt, weil der Backtrace eine relativ aufwendige Operation ist und das, wenn es häufig vorkommen sollte, die Performance schnell in den Keller treiben könnte. Außerdem reicht es ja, einen Fehler anzuzeigen - den man dann beheben sollte und sich dann auf den nächsten konzentrieren kann ;-).Klaus
-
[...] Außerdem reicht es ja, einen Fehler anzuzeigen - den man dann beheben sollte und sich dann auf den nächsten konzentrieren kann ;-).
Nun ja, bei ~30 aktivierten Plugins, kann die "Fehlerbehebung" dann wohl etwas dauern.
-
Man muss nicht alle Plugins gleichzeitig laden ;-).
Du kannst in thread.c in der Funktion cStateLockLog::Check() die Zeile
dumped = true;
auskommentieren. Dann zeigt er alle solchen Vorkommnisse an.
Klaus
-
[...] Dann zeigt er alle solchen Vorkommnisse an. ...
OK, habe ich mal gemacht und so wie es auf den ersten Blick aussieht, sind nur skindesigner und osd2web von diesem Problem betroffen.
Allerdings habe ich diese Meldung, die ich keinem Plugin zuordnen kann:
Code
Display MoreJun 04 21:13:47 [vdr] [19956] --- end invalid lock sequence report Jun 04 21:13:47 [vdr] [19956] --- begin invalid lock sequence report Jun 04 21:13:47 [vdr] [19956] 20816 - R - - R - - - - - L Jun 04 21:13:47 [vdr] [19956] 19956 - * - - * - - - - - U Jun 04 21:13:47 [vdr] [19956] 20816 R * - - * - - - - - L Jun 04 21:13:47 [vdr] [19956] 20816 - * - - * - - - - - U Jun 04 21:13:47 [vdr] [19956] 19956 - * - - - - - - - - U Jun 04 21:13:47 [vdr] [19956] 19956 - - - - - - - - - - U - Last output repeated twice - Jun 04 21:13:47 [vdr] [19956] 20816 - R - - - - - - - - L Jun 04 21:13:47 [vdr] [19956] 20816 - - - - - - - - - - U Jun 04 21:13:47 [vdr] [19956] 19956 R - - - - - - - - - L Jun 04 21:13:47 [vdr] [19956] 19956 - - - - - - - - - - U Jun 04 21:13:47 [vdr] [19956] 19956 - R - - - - - - - - L Jun 04 21:13:47 [vdr] [19956] 19956 - - - - - - - - - - U Jun 04 21:13:47 [vdr] [19956] 19956 - R - - - - - - - - L Jun 04 21:13:47 [vdr] [19956] 19956 R * - - - - - - - - L Jun 04 21:13:47 [vdr] [19956] 19956 - * - - - - - - - - U - Last output repeated twice - Jun 04 21:13:47 [vdr] [19956] 19956 - - - - - - - - - - U Jun 04 21:13:47 [vdr] [19956] 19956 - - - - R - - - - - L Jun 04 21:13:47 [vdr] [19956] 19956 - R - - * - - - - - L Jun 04 21:13:47 [vdr] [19956] 19956 invalid lock sequence: 2 Channels Jun 04 21:13:47 [vdr] [19956] full backtrace: Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr cStateLock::Lock(cStateKey&, bool, int) at thread.c:702 Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr cListBase::Lock(cStateKey&, bool, int) const at tools.c:2123 Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr cChannels::GetChannelsRead(cStateKey&, int) at channels.c:843 Jun 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 Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr main at vdr.c:1070 (discriminator 3) Jun 04 21:13:47 [vdr] [19956] /lib64/libc.so.6 __libc_start_main at ??:? Jun 04 21:13:47 [vdr] [19956] /usr/bin/vdr _start at ??:? Jun 04 21:13:47 [vdr] [19956] --- end invalid lock sequence report
-
Verdammt, jetzt habe ich es gerade geschaft alle Plugins für 2.3.5 in meinem PPA anzupassen und schon kommt 2.3.6
-
OK, habe ich mal gemacht und so wie es auf den ersten Blick aussieht, sind nur skindesigner und osd2web von diesem Problem betroffen.
Das muss noch nichts heissen. Das Ganze ist ja ein dynamischer Vorgang. Es kann also durchaus sein, daß bei bestimmten Aktionen oder Kombinationen von Aktionen noch Meldungen kommen. Hatte ich im Core-Code auch (siehe HISTORY).QuoteAllerdings habe ich diese Meldung, die ich keinem Plugin zuordnen kann:
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
-
sind nur skindesigner ... von diesem Problem betroffen.
Kann ich bestätigen, mein Test-VDR mit skindesigner Skin:
Code
Display MoreJun 4 22:41:22 vdr2 vdr: [1332] skindesigner: templates and images cached Jun 4 22:41:22 vdr2 vdr: [1332] skindesigner: cached 69 icons - size internal mem 0,05MB, high level mem 0,40MB Jun 4 22:41:22 vdr2 vdr: [1332] skindesigner: cached 201 logos - size 2463,96MB internal mem Jun 4 22:41:22 vdr2 vdr: [1332] skindesigner: cached 0 skinparts - size internal mem 0,00MB, high level mem 0,00MB Jun 4 22:41:22 vdr2 vdr: [1332] skindesigner: templates loaded and caches created - needed 1864 ms Jun 4 22:41:22 vdr2 vdr: [1332] --- begin invalid lock sequence report Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - W - - - - - - - - L Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - * - - W - - - - - L Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - * - - - - - - - - U Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - - - - - - - - - - U Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - W - - - - - - - - L Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - * - - W - - - - - L Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - * - - - - - - - - U Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - - - - - - - - - - U Jun 4 22:41:22 vdr2 vdr: [1332] 1332 - R - - - - - - - - L Jun 4 22:41:22 vdr2 vdr: [1332] 1332 - - - - - - - - - - U Jun 4 22:41:22 vdr2 vdr: [1332] 1332 - R - - - - - - - - L Jun 4 22:41:22 vdr2 vdr: [1332] 1332 - - - - - - - - - - U Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - W - - - - - - - - L Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - * - - W - - - - - L Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - * - - - - - - - - U Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - - - - - - - - - - U Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - W - - - - - - - - L Jun 4 22:41:22 vdr2 vdr: [1332] 1390 - - - - - - - - - - U Jun 4 22:41:22 vdr2 vdr: [1332] 1332 - R - - - - - - - - L Jun 4 22:41:22 vdr2 vdr: [1332] 1332 R * - - - - - - - - L Jun 4 22:41:22 vdr2 vdr: [1332] 1332 invalid lock sequence: 1 Timers Jun 4 22:41:22 vdr2 vdr: [1332] full backtrace: Jun 4 22:41:22 vdr2 vdr: [1332] /usr/bin/vdr cStateLock::Lock(cStateKey&, bool, int) at ??:? Jun 4 22:41:22 vdr2 vdr: [1332] /usr/bin/vdr cTimers::GetTimersRead(cStateKey&, int) at ??:? Jun 4 22:41:22 vdr2 vdr[1332]: invalid lock sequence at So. 04.06. 22:41 Jun 4 22:41:22 vdr2 vdr: [1332] /usr/lib/vdr/plugins/libvdr-skindesigner.so.2.3.6 cGlobalTimers::SetLocalTimers() at ??:? Jun 4 22:41:22 vdr2 vdr: [1332] /usr/lib/vdr/plugins/libvdr-skindesigner.so.2.3.6 cGlobalTimers::LoadTimers() at ??:? Jun 4 22:41:22 vdr2 vdr: [1332] /usr/lib/vdr/plugins/libvdr-skindesigner.so.2.3.6 cViewChannel::SetChannel(cChannel const*, int) at ??:? Jun 4 22:41:22 vdr2 vdr: [1332] /usr/bin/vdr cDisplayChannel::DisplayChannel() at ??:? Jun 4 22:41:22 vdr2 vdr: [1332] /usr/bin/vdr cDisplayChannel::cDisplayChannel(int, bool) at ??:? Jun 4 22:41:22 vdr2 vdr: [1332] /usr/bin/vdr main at ??:? Jun 4 22:41:22 vdr2 vdr: [1332] /lib/x86_64-linux-gnu/libc.so.6 __libc_start_main at libc-start.c:325 Jun 4 22:41:22 vdr2 vdr: [1332] /usr/bin/vdr _start at ??:? Jun 4 22:41:22 vdr2 vdr: [1332] --- end invalid lock sequence report
Und irgendwie ist die Formatierung dieser Zeile komisch, PID und ":" vertauscht:
Regards
fnu -
Und irgendwie ist die Formatierung dieser Zeile komisch, PID und ":" vertauscht:
Die Zeile wird in cStateLockLog::Dump() nach stderr geschrieben, was bei dir anscheinend auch im Log landet. Auf die Formatierung hat VDR hier keinen Einfluß.Klaus
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!