Red Hat Bugzilla – Bug 247747
xawtv crashes X11 on x86_64
Last modified: 2007-11-30 17:12:10 EST
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):
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:
Start xawtv from X11 terminal (gnome-terminal) command line.
The TV application should start _properly_, i.e. with proper scaled picture.
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:
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
(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
In both cases I got the very same identical crash, ruling out a driver problem,
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
> 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
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
v4lctl setchannel number
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
> v4lctl setchannel number
> 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
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
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]
Could you test this patch? It is just to test whether it is argv-related or
(rpmbuild -bc xawtv.spec
apply the patch
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
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
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
Maybe, due to the xvinfo problem, should you or I reassign the bug somewhere to
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
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
Well, I noticed that bttv uses the ioctl32_compat, maybe there is something
> 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"
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
> 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
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
OK, as you prefer.
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
The very same output is generated if the v4l kernel modules are removed
> 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?
(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?
> (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"?
> 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 bug has been marked as a duplicate of 250070 ***