vdr 1.4.4 / xineliboutput 1.0.0_pre6 causes complete system freeze

Message ID 200612031245.20431.jareguero@telefonica.net
State New

Commit Message

Jose Alberto Reguero Dec. 3, 2006, 11:45 a.m. UTC
  El Domingo, 3 de Diciembre de 2006 11:31, Matthias Dahl escribió:
> Hi everyone.
> I am currently trying to get away from MythTV (which never lived up to my
> expectations). So far, vdr has been nothing but great. Except for the
> following which just drives me crazy:
> Whenever I am using vdr-sfxe or xine-ui to watch tv, switching channels
> sometimes freezes my system hard... except for the Magic SysRq reboot key,
> its totally dead. (no remote logging, no emergency umounting, ...)
> So far I have been able to come up with a testcase that reproduces the
> problem or at least some problem...
> 1) start vdr as demon (with xineliboutput)
> 2) fire up vdr-sxfe (use a local pipe or rtsp or whatever) or xine xvdr://
> 3) send a SIGKILL to the frontend process (so either vdr-sxfe or xine)
> 4) system freezes hard immediately without any logs or whatsoever
> I believe this is the same problem I have been expierencing at random. I
> guess what happened previously was that vdr-sxfe or xine died unexpectedly
> and which naturally led to the same result.
> What's interesting though, starting vdr directly (not as demon) with the
> xineliboutput, I am unable to reproduce the problem. I can kill the
> process, zap around as much as I want... no problem.
> Here some more informations:
> - OS: Gentoo ~amd64 (64 bit -hicks-)
> - KNC ONE DVB-C Plus with Cineview and Alphacrypt Light CAM
> - fresh (a few days old) dvb tree from mercurial repository (linuxtv.org)
> - 2.6.19rc6git10 (almost 100% identical to 2.6.19-final)
> - xinelib 1.1.3_pre20061129
> - vdr 1.4.4 with bigpatch, setup plugin, jumpplay, dvbplayer, cmdsubmenu
>   dolby-record-switch, submenu and femon
> - xineliboutput 1.0.0_pre6
> - gcc 4.1.1 (gentoo rev 2, meaning there are a lot of fixes included and
> thus not vanilla)
> - glibc 2.5
> Naturally I also tried older kernels and older dvb checkouts but that
> didn't change anything. I do believe now that the problem is somewhere
> either in vdr or in xineliboutput because my system is normally rock solid
> and I cannot force a total freeze with just some dvb apps even if I want
> to. (believe me, I tried)
> Being an "computer scientist" myself, I know there is nothing more
> important than debugging the whole thing. Unfortunately that's hard to do
> when the whole system just takes a break. ;-) I tried getting getting some
> infos out of this with gdb but so far nothing turned up. There is also no
> kernel oops or anything like it reported.
> The strangest thing about this: vdr runs as vdr:vdr and vdr-sxfe is also
> just a regular user. Actually user processes shouldn't be able to freeze
> the system hard. ;-(
> By the way, I also opened up a post over at vdr-portal.de which turned up
> that I am not the only one seeing this problem.
> (german) http://www.vdr-portal.de/board/thread.php?postid=548719
> I also email Petri (author of xineliboutput) a few days ago with roughly
> the same msg here but I haven't yet received an answer.
> Thanks for any help or advice in advance! If there is anything I can do to
> help to get to the bottom of this, I'd be more than glad.
> Have a nice weekend,
> matthew.

I have the same problem.
The attached patch work for me.

Jose Alberto


Index: frontend_svr.c
RCS file: /cvsroot/xineliboutput/vdr-xineliboutput/frontend_svr.c,v
retrieving revision 1.27
diff -r1.27 frontend_svr.c
<   while(read(fd_control[cli], &m_CtrlBuf[ cli ][ m_CtrlBufPos[cli] ], 1) == 1) {
>   int n;
>   while((n = read(fd_control[cli], &m_CtrlBuf[ cli ][ m_CtrlBufPos[cli] ], 1)) == 1) {
>   if (n == 0) {
>     LOGMSG("Client connection %d closed", cli);
>     CloseConnection(cli);
>   }