1.3.27 doesn't seem quite NPTL ready, it always crashes at shutdown here on Fedora Core 4 (IIRC also on FC3 and 1.3.2x the last time I tried). No such problems when setting LD_ASSUME_KERNEL=2.4.1. The backtrace I'm able to obtain looks pretty much useless, but always practically the same, here goes anyway:
#0 0x00ddd223 in _Unwind_DeleteException () from /lib/libgcc_s.so.1 #1 0x00dddf82 in _Unwind_Backtrace () from /lib/libgcc_s.so.1 #2 0x00dde015 in _Unwind_ForcedUnwind () from /lib/libgcc_s.so.1 #3 0x00b65c5e in _Unwind_ForcedUnwind () from /lib/libpthread.so.0 #4 0x00b63cc7 in __pthread_unwind () from /lib/libpthread.so.0 #5 0x00b5e3a8 in sigcancel_handler () from /lib/libpthread.so.0 #6 0x00b6f440 in __kernel_sigreturn () #7 0x00b6f402 in __kernel_vsyscall () #8 0x008e6ee6 in __nanosleep_nocancel () from /lib/libc.so.6 #9 0x0091dce7 in usleep () from /lib/libc.so.6 #10 0x00159b82 in ?? () #11 0x00002710 in ?? () #12 0xffffffff in ?? () #13 0x00000000 in ?? () (gdb)
(Yes, I have the debug symbols for VDR available and installed.)
This is a pretty much patched VDR with lots of plugins, neither of which I can really disable. Perhaps someone with a more vanilla setup can reproduce?
Ville Skyttä wrote:
1.3.27 doesn't seem quite NPTL ready, it always crashes at shutdown here on Fedora Core 4 (IIRC also on FC3 and 1.3.2x the last time I tried). No such problems when setting LD_ASSUME_KERNEL=2.4.1. The backtrace I'm able to obtain looks pretty much useless, but always practically the [...] This is a pretty much patched VDR with lots of plugins, neither of which I can really disable. Perhaps someone with a more vanilla setup can reproduce?
Broken plugins can cause such crashes at shutdown. Only enable one at a time to find out which one(s).
cu Ludwig
On Sun, 2005-06-19 at 19:49 +0200, Ludwig Nussel wrote:
Ville Skyttä wrote:
1.3.27 doesn't seem quite NPTL ready, it always crashes at shutdown here on Fedora Core 4 (IIRC also on FC3 and 1.3.2x the last time I tried). No such problems when setting LD_ASSUME_KERNEL=2.4.1. The backtrace I'm able to obtain looks pretty much useless, but always practically the [...] This is a pretty much patched VDR with lots of plugins, neither of which I can really disable. Perhaps someone with a more vanilla setup can reproduce?
Broken plugins can cause such crashes at shutdown. Only enable one at a time to find out which one(s).
Ok, it's wapd.
The culprit seems to be cWapServer::Action() in server.c, which I tried to convert to use cCondWait::SleepMs() instead of usleep(), and added an "active" boolean into the class that would control the while loop in Action() and that would be set to false in the destructor, but those changes did not help.
More ideas?
Ville Skyttä wrote:
The culprit seems to be cWapServer::Action() in server.c, which I tried to convert to use cCondWait::SleepMs() instead of usleep(), and added an "active" boolean into the class that would control the while loop in Action() and that would be set to false in the destructor, but those changes did not help.
(without taking any close look at the source code) I assume this is a main while loop in a cThread. Stopping a thread from within the destructor is quite risky, as the object is already partially destructed, and if you dont explicitly wait for the thread to finish, the object may be gone before the thread ends.
The best way is to stop the thread before the object gets destroyed, using some thread.Stop(). The right place for stopping threads is in cPlugin::Stop().
Cheers,
Udo
On Mon, 2005-06-20 at 15:47 +0200, Udo Richter wrote:
Ville Skyttä wrote:
The culprit seems to be cWapServer::Action() in server.c, which I tried to convert to use cCondWait::SleepMs() instead of usleep(), and added an "active" boolean into the class that would control the while loop in Action() and that would be set to false in the destructor, but those changes did not help.
(without taking any close look at the source code) I assume this is a main while loop in a cThread. Stopping a thread from within the destructor is quite risky, as the object is already partially destructed, and if you dont explicitly wait for the thread to finish, the object may be gone before the thread ends.
The best way is to stop the thread before the object gets destroyed, using some thread.Stop(). The right place for stopping threads is in cPlugin::Stop().
Okay, I think I may have got it, thanks. The attached patch seems to fix the crash here. Dunno if the usleep changes were actually necessary but since I already had them available...
Ville Skyttä wrote:
1.3.27 doesn't seem quite NPTL ready, it always crashes at shutdown here on Fedora Core 4 (IIRC also on FC3 and 1.3.2x the last time I tried). No such problems when setting LD_ASSUME_KERNEL=2.4.1. The backtrace I'm able to obtain looks pretty much useless, but always practically the same, here goes anyway:
VDR (1.3.27) has recently been crashing frequently during playback of recordings. First sign is that VDR stops responding to remote control (ie no OSD on remote press) then shortly afterwards VDR crashes.
I am running an uptodate system ( Debian SID, kernel 2.6.12-mm2, em8300 cvs, vdr-dxr3-0.2.3-cvs20050622 )
Setting LD_ASSUME_KERNEL=2.4.1 seems to have fixed the problem.
-RichardW.
Richard Wall wrote:
Ville Skyttä wrote:
1.3.27 doesn't seem quite NPTL ready, it always crashes at shutdown here on Fedora Core 4 (IIRC also on FC3 and 1.3.2x the last time I tried). No such problems when setting LD_ASSUME_KERNEL=2.4.1. The backtrace I'm able to obtain looks pretty much useless, but always practically the same, here goes anyway:
VDR (1.3.27) has recently been crashing frequently during playback of recordings. First sign is that VDR stops responding to remote control (ie no OSD on remote press) then shortly afterwards VDR crashes.
Does it also happen if you remove the sleep in cDvbPlayer?
http://www.suse.de/~lnussel/vdr/vdr-1.3.25-dvbplayer-nosleep.diff
cu Ludwig
On 06/07/05 11:42 Ludwig Nussel wrote:
Richard Wall wrote:
VDR (1.3.27) has recently been crashing frequently during playback of recordings. First sign is that VDR stops responding to remote control (ie no OSD on remote press) then shortly afterwards VDR crashes.
Does it also happen if you remove the sleep in cDvbPlayer? http://www.suse.de/~lnussel/vdr/vdr-1.3.25-dvbplayer-nosleep.diff
I applied it but get this...
vito:/usr/local/src/vdr/VDR# vdr -l 3 -c /var/local/lib/vdr -E /var/local/lib/vdr/epg.data -L /usr/local/lib/vdr -v /srv/vdr -Pdxr3 vdr: pthread_mutex_lock.c:78: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. Aborted
...but without the dxr3 plugin it's okay. Your patch applied cleanly, despite being on 1.3.27.
Any ideas?
-RichardW.
On 06/07/05 13:19 Richard Wall wrote:
I applied it but get this...
vito:/usr/local/src/vdr/VDR# vdr -l 3 -c /var/local/lib/vdr -E /var/local/lib/vdr/epg.data -L /usr/local/lib/vdr -v /srv/vdr -Pdxr3 vdr: pthread_mutex_lock.c:78: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. Aborted
Ah, sorry, I'd forgotten to install after compile :-(. Works fine now. Will let you know if it improves playback reliability. Thanks for your help Ludwig.
-RichardW,
On 06/07/05 11:42 Ludwig Nussel wrote:
Richard Wall wrote:
VDR (1.3.27) has recently been crashing frequently during playback of recordings. First sign is that VDR stops responding to remote control (ie no OSD on remote press) then shortly afterwards VDR crashes.
Does it also happen if you remove the sleep in cDvbPlayer? http://www.suse.de/~lnussel/vdr/vdr-1.3.25-dvbplayer-nosleep.diff
It doesn't crash, but the osd / remote stop responding after a while. Using LD_ASSUME_KERNEL=2.4.1 it works fine. Oh well.
Does that patch change the way the recordings are ordered. Seems to me that since applying it any % prefixes are ignored. Or perhaps I just hadn't noticed before.
Thanks.
-RichardW.
Richard Wall wrote:
On 06/07/05 11:42 Ludwig Nussel wrote:
Richard Wall wrote:
VDR (1.3.27) has recently been crashing frequently during playback of recordings. First sign is that VDR stops responding to remote control (ie no OSD on remote press) then shortly afterwards VDR crashes.
Does it also happen if you remove the sleep in cDvbPlayer? http://www.suse.de/~lnussel/vdr/vdr-1.3.25-dvbplayer-nosleep.diff
It doesn't crash, but the osd / remote stop responding after a while. Using LD_ASSUME_KERNEL=2.4.1 it works fine. Oh well.
Maybe the dxr3 plugin you are using is not NPTL ready.
Does that patch change the way the recordings are ordered. Seems to me that since applying it any % prefixes are ignored. Or perhaps I just hadn't noticed before.
No.
cu Ludwig
Richard Wall wrote:
Does that patch change the way the recordings are ordered. Seems to me that since applying it any % prefixes are ignored. Or perhaps I just hadn't noticed before.
AFAIK the sorting depends on your locale environmental variables. I have (Mandriva) the line: . /etc/profile in the beginning on my VDR script, so that it loads the system default locale environmental variables.
-
Anssi Hannula -
Ludwig Nussel -
Ludwig Nussel -
Richard Wall -
Udo Richter -
Ville Skyttä