Version: kdetv version 0.8.9-1 (using KDE KDE 3.5.7) Installed from: Debian testing/unstable Packages OS: Linux I have tested kdetv for more than 3 months now. It have been useful to listen/watch tv while doing other tasks on my computer. I have tested many of its configurations/options but finally i just got feed up of it crashing my computer. The most common cause for it to crash is: if one user has it running, when another user start it on its desktop, the application crashes for good. another situation in wich it crashes is: if for any reason the desktop is closed with this application running, the desktop will try to start it at start-up time. Automatically it crashes. The crashed application should be abble to restart, reopen, you may think. Wrong, dead wrong. The most anoying thing, and what i just can't live with anymore, is that is just locks in memory and there is nothing that could be done to clear it. One shure way to detect this is happening is that a simple "ps -aux" just locks in also. It lists to some point and then just stops. When in this situation no kill or even reboot works. Pull the plug is the only corrective action allowed. An application that forces you to use the power button is NO aceptable. I have check/read previous bug reports about this application crashing. The comments about glx, nvidia, wrong compilation are NOT applicable.
Same here... kdetv 0.8.9 built on a CentOS5 machine I can't close the kdetv process, even kill -9 as root doesn't close it. 'ps -aux' hangs, 'w' hangs too. Only reboot solves things. Even though kdetv is still running in the background, I can't get it to foreground either, trying to start a second instance gives 'Unable to grab video' dmesg doesn't show any hints, neither does /var/log/messages
Hi, I have the same problem here. Im suffering from this bug since a very long time now, I think 1-2 years. I never filed a bug report because IMHO its a kernel-related problem ("ps aux" hangs) and I am using the Nvidia closed source driver that taints the kernel... bad for bug reports. The crash happens here when closing kdetv. From 10 times I close it, 7 crashes appear. When crashing, the main window disappears, but the sound remains unmuted. Restarting kdetv results in the error message already described, and a "ps aux" hangs befor kdetv is shown. During system shut down, everything freezes, because some system deamon seems to perform a "ps aux" and crashed indefinetly. After rebooting the system and logging in into KDE, kdetv restarts immediately. It seems that it was still active during session shutdown. The problem arises again, when you close the app because you do not want to watch TV, it crashes again in 7/10 times... very annoying. Currenty, my system consits of: Dual CPU: 2x AMD MP 2000+ Nvidia GF4 TI4600 KDE 3.5.8 kdetv 0.8.9 Kernel 2.6.22 Gentoo Linux IMHO its a kernel related bug... a userland application should never be able to crash a running system. Hope it helps, Florian
Sorry, I forgot an impotant information: Its a Hauppauge TV-Card, PCI, with FM radio. It uses the bttv driver.
It is however initiated by kdetv, because other TV viewer apps such as Zapping don't cause the same issues (at least not on my system, something for you to check as well) For the record, my setup kdetv 0.8.9 KDE 3.5.4 , CentOS5/RHEL5 stock RPM's Intel P4 2.8GHz machine, ATI 9800Pro videocard, Pinnacle PCTV Studio/Rave
Interestingly, I was never able to crash kdetv when it was started within "strace". Pleace, try starting it with "strace kdetv"... lots of output appears, but I am not able to crash it... perhaps some kind of race condition? Regards, Florian
Confirmed : starting 'strace kdetv' indeed means nothing remains in memory after closing kdetv, so no errors/hangups. I wish mr Ziegelmeier would join in to try and locate the problem.
Please have at look at this: http://forums.gentoo.org/viewtopic-t-629024.html I got kdetv to freeze within strace! :-) --- gettimeofday({1201211925, 930683}, NULL) = 0 gettimeofday({1201211925, 930773}, NULL) = 0 gettimeofday({1201211925, 930825}, NULL) = 0 gettimeofday({1201211925, 930869}, NULL) = 0 gettimeofday({1201211925, 930931}, NULL) = 0 gettimeofday({1201211925, 930977}, NULL) = 0 gettimeofday({1201211925, 931061}, NULL) = 0 gettimeofday({1201211925, 931118}, NULL) = 0 gettimeofday({1201211925, 931349}, NULL) = 0 ioctl(5, FIONREAD, [0]) = 0 write(6, "\0", 1) = 1 write(3, "\n\23\2\0\7\0`\4\31\0\v\0\7\1\0\0\0\0\30\0\22\0\0\0\7\1\0\0\7\0`\4"..., 52) = 52 ioctl(5, FIONREAD, [1]) = 0 ioctl(12, VIDIOC_STREAMOFF, 0xbfc26c60) = 0 munmap(0xb52bb000, 1028096 ------- Looks like a "munmap" causes the crash during closing. Any ideas?! Again, this cannot be a bug of kdetv alone... IMHO, an defective application must not be able to crash the kernel. Otherwise, somebody would be able to isolate the bug to a minimal fragment of code and would have a neat kernel crasher! As a consequence, this would have to be fixid within the kernel. Regards, Florian
Created attachment 23259 [details] tail of strace of kdetv crash kdetv during strace. kdetv closed, crashed, strace froze. florian@powerstation ~ $ kdetv -v Qt: 3.3.8 KDE: 3.5.8 kdetv: 0.8.9 florian@powerstation ~ $
/me <-- Original poster of that Gentoo forum thread Problem occurs on shutdown of KDETV, if sound is still audible, the machine is doomed. No other problems whatsoever with that application. This happens only on my AMD64 workstation, on another machine (Pentium III with i686 setup) with exactly the same software setup (meaning same distro and especially application and kernel versions) this shutdown problem does not appear. I can confirm the "ps ..." issue and the hangups on shutting down the machine. No difference between using original V4L1 or compatibility layer. Had no trouble with other (older) OSes on this machine, having had OpenSuSE 10.0 (64bit) and Windows XP (32bit). Software: * KDETV 0.8.9 * KDE 3.5.8 (trouble since 3.5.6 at the time of setting up the workstation) * Kernel 2.6.23 (trouble since 2.6.18 at the time ... yeah, look above) * Xorg server 1.3.0.0-r4 * bttv driver version 0.9.17 * nVidia driver 100.14.19 Hardware: * Asus A8N-SLI Deluxe, nVidia nForce4 Ultra * AMD Athlon64 X2 4200+ * Hauppauge WinTV PCI (card=10, PCI ID 0070:13eb, model #44354, tuner=20) * nVidia GeForce 6600LE Ehrm ... did I miss something?
Is this relevant? http://lkml.org/lkml/2007/9/9/138 Sorry I have no clue about kernel debugging... but it looks interesting: "The actual app that does that is kdetv on exit". Unfortunately, no answer yet... Greetings, Florian
> I found a bug (circular lock dependency) in generic videobuf code Means the problem is caused by a deadlock in kernel code ... > Suppose app has two threads, and one calls munmap() on a video buffer , and second calls VIDIOC_QBUF ioctl. > (The actual app that does that is kdetv on exit) ... and it is revealed through specific programming techniques by accessing the kernel via multiple threads in this particular KDE application we are talking about. At least a clue why the lock doesn't appear during the use of other TV software. So who is going to care about it? A workaround in KDETV or a fix in the kernel code? I can only guess about the priority this bugfix would get during kernel development, and I believe it won't be one of the top issues. In the meantime it would be advisable to use other TV software, which doesn't trigger that kernel deadlock.
No answer at the Linux Kernel Mailing List since the original bug report, but http://bugzilla.kernel.org/show_bug.cgi?id=5339 shows a bit more of activity. Well, at least somebody replied ;-) I posted a comment with references to this bug report, the LKML posting an my Gentoo forum thread. Perhaps someone reacts to it.
Hi, this bug was fixed upstream (kernel) some months ago. It was caused by a race condition / recursively entered mutex within the video subsystem of the kernel. Please close / mark as fixed upstream. Thanks, Florian
The KDETv main developer confirmed me by mail that the project is unmaintained since 4 years ago. Closing bug reports as UNMAINTAINED. Regards