Description of problem: The xawtv program ,in the x86_64 version, when started without parameters, crashes the X11 server, restarting the session from scratch (gdm). Version-Release number of selected component (if applicable): xawtv-3.95-3.fc7 How reproducible: Always, without parameters. With some parameters, like "0dga" it might work, even if the output is not always as it should be (unscaled) and the root password is requested. Note that "0dga" it NOT a xawtv parameter, and others, like "-nodga" or "-gl -nodga" or "-xv -nodga" might crash X11 as well. Steps to Reproduce: 1. Start xawtv from X11 terminal (gnome-terminal) command line. Actual results: X11 crashes Expected results: The TV application should start _properly_, i.e. with proper scaled picture. Additional info: The system has an nVidia card, this happens with the "nv" and with the "nvidia" driver in the very same way, so it does not seem to be a driver issue. The i386 version, on different, i386 only, PC runs, apparently fine. The last lines of /var/log/Xorg.0.log.old are: Backtrace: 0: /usr/bin/Xorg(xf86SigHandler+0x6d) [0x48b99d] 1: /lib64/libc.so.6 [0x3c75a30620] 2: /usr/bin/Xorg(Dispatch+0x130) [0x44b9f0] 3: /usr/bin/Xorg(main+0x45d) [0x43480d] 4: /lib64/libc.so.6(__libc_start_main+0xf4) [0x3c75a1daa4] 5: /usr/bin/Xorg(FontFileCompleteXLFD+0x229) [0x433ad9] Fatal server error: Caught signal 11. Server aborting
It is a known issue. The same was on my ATI Radeon, until the recent version of xorg-x11 driver for that card. IMHO at one moment xorg-x11 had lacked something to support overlay mode (needed for xawtv), and now it fixes it drive by drive... Try a work-around: xawtv -noxv -remote 0:0 How "tvtime" works on your system? It is the default TV viewer now. The main idea of "xawtv" package in Fedora is to provide some useful additional utilities (still missing in tvtime and friends). The regular video watching with xawtv unfortunately might crash with new X.org software, and such a crashung is too hard to debug. I would recommend to use tvtime in your case, or try a work-around above.
(In reply to comment #1) > It is a known issue. The same was on my ATI Radeon, until the recent version of > xorg-x11 driver for that card. > > IMHO at one moment xorg-x11 had lacked something to support overlay mode (needed > for xawtv), and now it fixes it drive by drive... Well, maybe, but the problem shows up with both "nv" and "nvidia" drivers and only in the x86_64 architecture. The one installed on a i386 machine works pretty fine. This one has also an nvidia card with nvidia driver. > Try a work-around: > > xawtv -noxv -remote 0:0 This might work, as I mentioned, the "0dga" option (which does not exists) make it work. Which makes me think that something is wrong somewhere in "xawtv". > How "tvtime" works on your system? It is the default TV viewer now. The main "tvtime" works fine ,bat it has several drawbacks. First of all, it seems it does not support overlay mode (maybe I'm wrong) which results in high CPU usage. Not always an high quality deinterlacer/scaler is needed, sometimes the graphic card capabilities are enough. Second, the user interface, for channel zapping, is pretty poor. The main reason for "xawtv" is the "right (or left?) mouse button channel list", which enables the user to jump directly to one channel of choice. Useful in many cases. Last, and maybe most important, the channel tuning of "tvtime" does not use the TeleText information to retrieve the channel name (which "xawtv" does) leaving the user only with a channel number (and eventually to edit manually the channel list). I know that in US TeleText is not common, but this feature is really nice. In other words, despite its age, "xawtv" still seems to have some interesting options, which are missing in "tvtime". BTW, I also tried "zapping", with mixed results.
> the "0dga" option (which does not exists) Could you explain something more about this? > both "nv" and "nvidia" drivers You mean free "nv" and proprietary "nvidia" ?
(In reply to comment #3) > > the "0dga" option (which does not exists) > Could you explain something more about this? Well, this is really very strange. Suspecting an "xv" (or overlay) problem, I tried with "-dga", this was working, but I mistyped, so instead of "-" I typed "0", which is close on the keyboard. Once I retried with "-dga", it was not working, crashing as in the other cases. Re-retrying with "0dga" got it working, again. I've absolutely no idea of what "0dga" is causing. Maybe it just fill some buffer with some data. If you need, I'll try other possibilities (this evening, I do not have the PC with me know) in order to gather more information. One for sure will be the "-noxv -remote 0:0". > > both "nv" and "nvidia" drivers > You mean free "nv" and proprietary "nvidia" ? Yep, at first I was using the proprietary "nvidia". To be sure this was not the cause (which sometimes happens), I tried the free "nv", the default one, so to speak. In both cases I got the very same identical crash, ruling out a driver problem, I guess. Keep in mind that, again, this happens only on x86_64 architecture, not on i386. One difference that comes into my mind, is that the i386 installation has the tv-fonts from xawtv package, while the x86_64 has not, since these are not required, it seems. The Xorg error has some reference to fonts, this might be a reason. I'll try to install the fonts and I'll report the results (again, later this evening).
> ruling out a driver problem Could you try xawtv on some x86_64 with another type of card (not nvidia)? To ruling out a "type of hardware" problem... > Re-retrying with "0dga" got it working, again. Interesting... Specifying "xawtv 0dga", you tell "xawtv" to switch to a channel "0dga". When there is no such a channel (either builtin channel name (by frequency), or some configured name), IMHO xawtv starts with some default (first configured channel). Could you try various "xawtv something" combinations? Including "xawtv '' " (an empty, but specified argument). Does "xawtv something" actually never produces the crash? (If so, it could be some convenient start step to solve the issue).
(In reply to comment #5) > Could you try xawtv on some x86_64 with another type of card (not nvidia)? To > ruling out a "type of hardware" problem... Unfortunately not, I've only one machine with x86_64 architecture, with integrated (nVidia) graphic card and no other type of cards available. I might try to get some ATI, but I cannot promise anything > Interesting... Specifying "xawtv 0dga", you tell "xawtv" to switch to a channel > "0dga". When there is no such a channel (either builtin channel name (by > frequency), or some configured name), IMHO xawtv starts with some default (first > configured channel). > > Could you try various "xawtv something" combinations? Including "xawtv '' " (an > empty, but specified argument). Does "xawtv something" actually never produces > the crash? (If so, it could be some convenient start step to solve the issue). OK, let's go. "xawtv xyz", where "xyz" could be (at least it seems it could be) any string, including the empty one '', does not crash X11. Depending on the string, xawtv could report something like 'station "xyz" not found', but not always. As I wrote, no crash, but scaling does not work, i.e. picture size is 768x576 (extended PAL size), with black borders. I tried also "xawtv -noxv -remote 0:0". Also in this case no crash and, differently from above, the scaler is working. Note that, it seems the CPU usage is quite high, "top" shows 20% for "xawtv". So, I tried "xawtv -noxv-video -remote 0:0", which resulted again in a perfect working system, including scaling, but with only around 3% CPU load. "xawtv -noxv-image -remote 0:0" resulted in a black picture, but with audio, i.e. channel tuning was working. Also, it seems that without "-remote 0:0" the picture is black, as above. Installing the "xawtv-tv-fonts" did not make a difference. Hope this helps.
Could you check (instead of "xawtv xyz") also: v4lctl setstation xyz xawtv or: v4lctl setchannel number xawtv i.e. to check whether the prior channel setting affects the issue.
(In reply to comment #7) > Could you check (instead of "xawtv xyz") also: > > v4lctl setstation xyz > xawtv > > or: > > v4lctl setchannel number > xawtv > > i.e. to check whether the prior channel setting affects the issue. > In all cases (with or without real station or channel) xawtv crashed X11 as originally reported. I guess the tuning is not an issue. Maybe something with argc/argv and, possibly some pointer to int cast, which will force the pointer to 32 bit. I'll try the 32 bit version (from F7.i386) in the x86_64 environment and see if this changes anything.
OK, I tried the 32 bit version in the 64 bit environment (will all requested 32 bit dependencies) and it crashed as well. So, maybe if there is a pointer problem it might not be specific to a 64 bit situation.
Could you re-compile xawtv on your x86_64 machine? (I mean "rpm -i *.src.rpm; cd ..../SPECS; rpmbuild -bc xawtv.spec) If yes, I would ask you to do some more tests... Do you use the latest kernel?
(In reply to comment #10) > Could you re-compile xawtv on your x86_64 machine? > (I mean "rpm -i *.src.rpm; cd ..../SPECS; rpmbuild -bc xawtv.spec) > > If yes, I would ask you to do some more tests... No problem. I've already installed the src.rpm and tried to build the package without all the patches, but the final result did not improve... Anyway, if you have other suggestions I could try them. > Do you use the latest kernel? Everything is up to date.
Created attachment 159780 [details] test 1 Fine! Could you test this patch? It is just to test whether it is argv-related or not. (rpmbuild -bc xawtv.spec apply the patch make ...)
OK, patch applied. xawtv then works as per "0dga" (or else) on the command line. That is, no crash and picture is there, even if it is not scaled. Going back, one thing I forgot to mention in the original report (I noticed only now). When crashing, xawtv has enough time to set up the channel and even to display something, i.e. a picture appears just moments before X11 goes down. I do not know what this could mean, but maybe it is somehow connected to something missing on the command line.
There is an issue wiith v4l-conf, reported just recently. Currently you cannot run it without prompt for root password. Since xawtv already try to invoke v4l-conf, it seems that in your case (because of root password issue) it is not actually run, hence v4l stuff remain unconfigured a little... Could you try to run "v4l-conf" (and enter root password if it ask for it, it will go away in the nearest future :) ), and then run the original (not patched) xawtv without args?
Well, first of all, with the "nvidia" driver it complains about the missing DGA extension, but it seems to setup something. Starting xawtv crashes X11 as usual. With the "nv" driver, it does not complain anymore, but xawtv crashes X11 as well. One thing I have to say, it seems xawtv tend to default to "dga" mode, which is unsupported by nVidia and it is anyway unsafe. On an i386 machine, xawtv alone does not work (missing DGA extension, due to nVidia driver), while "xawtv -nodga" asks for the root password as it would like to setup something. The funny thing is that giving the root password or not (cancel) does not change a bit, it works fine (but no scaler). Anyway, why the "no argv" patch was having the thing working?
"no argv" patch just comment out "drv->getfreq()" call. To go further, could you please run the crashed xawtv under strace, i.e. "strace -x xawtv 2>xawtv.log" Perhaps the output will be long enough to publish it at bugzilla -- feel free to send it to my email directly.
As it crashes with Xvideo enabled only, what is your "xvinfo" output?
Created attachment 159981 [details] gzipped output of strace -x xawtv 2>xawtv.log OK, here is the strace output. I compressed it, because the text file was 220KiB. About xvinfo, funny enough (!) it crashes X11 as well... So, I tried mplayer -vo xv -tv driver=v4l2 tv://e6 and it worked fine, without crashes... Maybe, due to the xvinfo problem, should you or I reassign the bug somewhere to xorg-x11?
You mean that running xvinfo crashes X11 even without any touch of xawtv? If so, it seems the issue is related to Xvideo component of xorg-x11-drv-v4l driver. When you invoke xvinfo, (run it on non-crashed i386 for comparison) it tryes to read XV_FREQ attribute too... Whats happen if you disable "v4l" driver in /etc/X11/xorg.conf in "Module" section? Do your non-crahsed i386 and crashed x86_64 systems have the same or different v4l hardware? If different, is it possible to test the crash with other v4l card? Does "xvinfo" work at all on x86_64 (if you remove v4l hardware or rmmod the correspond kernel drivers)? It seems that xorg-x11-drv-v4l uses old "v4l1" API (not the current "v4l2" API), but this old API should be still supported (if "v4l1_compat" kernel module is loaded). Xawtv has a "drv1-v4l.so" driver, using of it could show whether it is v4l-compatibility issue or not. But there is no good way to cause xawtv to use this driver, just temporary move "/usr/lib64/xawtv/drv0-v4l2.so" to another place... > I tried mplayer -vo xv -tv driver=v4l2 tv://e6 and it worked fine Mplayer by its design first grabs data to its memory, then put it to your graphic card through Xvideo extension. Xawtv uses Xvideo for both graphic card and v4l (by xorg-x11-drv-v4l driver), to put data directly from v4l card to graphic card (or something similar, I'm not a X11 guru). > reassign the bug somewhere to xorg-x11? Let's first test something more, while we hold "good repeated bug" in our hands. :)
(In reply to comment #19) > You mean that running xvinfo crashes X11 even without any touch of xawtv? Yep, it crashes as xawtv, without any touch to it... I straced xvinfo and it seems X11 goes down just after the XV_FREQ query. I'll attach the output of strace for it. > If so, it seems the issue is related to Xvideo component of xorg-x11-drv-v4l driver. Well, I noticed that bttv uses the ioctl32_compat, maybe there is something fishy there. > When you invoke xvinfo, (run it on non-crashed i386 for comparison) it tryes to > read XV_FREQ attribute too... In fact and this seems to be the problem. But why tvtime and maplyer don't suffer from the same issue? Shouldn't they also perform the same XV_FREQ query? > Whats happen if you disable "v4l" driver in /etc/X11/xorg.conf in "Module" section? Well, xawtv works fine and xvinfo is OK too, I'll attach the output of this one in this case. Note that, with the "nvidia" driver, the missing DGA extension error is reported by xawtv, so "-nodga" is needed and consequently the root password. With the "nv" driver, xawtv asks for the root password directly. > Do your non-crahsed i386 and crashed x86_64 systems have the same or different > v4l hardware? If different, is it possible to test the crash with other v4l card? The TV card is the same in both case, i.e. exactly the same, I've only one... Unfortunately, at the moment, the i386 hardware is not anymore available, so I cannot re-try with it. > Does "xvinfo" work at all on x86_64 (if you remove v4l hardware or rmmod the > correspond kernel drivers)? With v4l removed from xorg.conf or (exclusively, one or the other case) with the v4l modules removed, xvinfo works and produces the same identical ouput. > It seems that xorg-x11-drv-v4l uses old "v4l1" API (not the current "v4l2" API), > but this old API should be still supported (if "v4l1_compat" kernel module is > loaded). > Xawtv has a "drv1-v4l.so" driver, using of it could show whether it is > v4l-compatibility issue or not. But there is no good way to cause xawtv to use > this driver, just temporary move "/usr/lib64/xawtv/drv0-v4l2.so" to another place... Tried this, with v4l enabled in xorg.conf of course, and it crashed X11 as usual... > Mplayer by its design first grabs data to its memory, then put it to your OK, but, as mentioned above, what about the XV_FREQ query? Are they not doing it? And what about the same query for tvtime? Or maybe they do the v4l2 query, while xawtv and xvinfo do the v4l1 (assuming these are two different ones)? > Let's first test something more, while we hold "good repeated bug" in our hands. :) OK, as you prefer. bye, pg
Created attachment 160056 [details] strace of xvinfo crashing X11 Generated with strace -x xvinfo 2>xvinfo.log
Created attachment 160057 [details] xvinfo output without v4l This output was generated removing the v4l module from xorg.conf and using the "nv" driver. The very same output is generated if the v4l kernel modules are removed instead.
> why tvtime and maplyer don't suffer from the same issue? > Shouldn't they also perform the same XV_FREQ query? Both tvtime and mplayer uses the v4l kernel driver directly, i.e. to get freq they do VIDIOC_G_FREQUENCY ioctl. The same way does "xawtv -noxv". But when xawtv invoked without "-noxv" option, it uses Xvideo extension of "v4l" X11 driver (note there are two "Xvideo"s -- for graphic card and for v4l device), and therefore uses specific XV_FREQ Xvideo attribute to get the frequency. Then xorg-x11-drv-v4l actually asks for frequency the v4l hardware, but it seems that it uses old v4l1's API ioctl VIDIOCGFREQ for it, not v4l2's VIDIOC_G_FREQUENCY. Since "v4l-compat" kernel module is loaded, it does not produce any problems... I forgot to mention that after the temporary moving of drv0-v4l2.so, you should try xawtv with "-noxv" (else it will continue to use Xvideo and XV_FREQ). Try "-v 1" for debug output: xawtv -noxv -v 1 2>&1 | grep vid-open you should see whether xawtv actually touches drv1-v4l.so or not... This test should show whether it is some "v4l1 compatibility" issue or "X11 v4l" driver issue itself.
Perhaps have found something in xorg-x11-drv-v4l. Could you build and install this rpm on your 64bit system and try xawtv then? http://dmitry.butskoy.name/xawtv/xorg-x11-drv-v4l-0.1.1-5.1.src.rpm (i.e., rpmbuild as usual, then "rpm -U", then complete restart of X server (init 3; init 5) )
(In reply to comment #24) > Perhaps have found something in xorg-x11-drv-v4l. > > Could you build and install this rpm on your 64bit system and try xawtv then? > > http://dmitry.butskoy.name/xawtv/xorg-x11-drv-v4l-0.1.1-5.1.src.rpm > > (i.e., rpmbuild as usual, then "rpm -U", then complete restart of X server (init > 3; init 5) ) It seems you got it! Upgrading the v4l driver of xorg did the trick. Now xawtv works (without scaling, but this was also on the i386) and xvinfo works too. So it was something in the xorg component and not in xawtv. What will happen now? Should we wait until xorg recognize your patch and then, if everything is fine, close this bug? Since we are here, I do have another, almost unrelated topic. Maybe we can continue by email, if you're interested. I've compiled myself alevt, the teletext application (BTW are you interested in the srpms file? Someone could push this to fedora, since a teletext application is really really missing, AFAIK). When tvtime or xawtv are running together with alevt (required, for the tuning), the channel change takes very long, more than 1 second. Without alevt the channel change is almost immediate. On the i386 machine there was no problem, i.e. the channel change was almost immediate with or without alevt running. Do you have any idea how this could be "checked"? Thanks, pg
> I've compiled myself alevt, the teletext application (BTW are you interested in > the srpms file? If it yet not in Fedora, well, send me e-mail directly. > the channel change takes very long, more than 1 second. Looks similar to some locking issue. AFAIK, the x86_64 kernel has some differencies with i386 (besides the arch-dependent part), maybe it is because of this... *** This bug has been marked as a duplicate of 250070 ***