Bug 148119

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