Bug 66492
Summary: | Xconfigurator causes segmentation fault | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Henry Tieding <hwtieding> | ||||||||||||||
Component: | Xconfigurator | Assignee: | Mike A. Harris <mharris> | ||||||||||||||
Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> | ||||||||||||||
Severity: | high | Docs Contact: | |||||||||||||||
Priority: | medium | ||||||||||||||||
Version: | 7.3 | CC: | aadhodson, olivier.baudron | ||||||||||||||
Target Milestone: | --- | ||||||||||||||||
Target Release: | --- | ||||||||||||||||
Hardware: | i386 | ||||||||||||||||
OS: | Linux | ||||||||||||||||
Whiteboard: | |||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||
Clone Of: | Environment: | ||||||||||||||||
Last Closed: | 2002-08-05 14:14:06 UTC | Type: | --- | ||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
Embargoed: | |||||||||||||||||
Attachments: |
|
Description
Henry Tieding
2002-06-11 12:43:51 UTC
All bug reports in bugzilla must directly contain all of the details pertaining to the bug. Engineers do not have access to view help ticket details, RHN registration details, nor other customer information. I'll need to know what specific video hardware you've got, as well as a complete step by step description of how you are able to reproduce the problem. "lspci -n" output will provide the video hardware details. Also, if you've got config files spit out by Xconfigurator, please attach them, and an X server log if possible to the bug report by using the link below. Thanks. Starting from a fully operational 7.2 workstation, I did a server install of 7.3. The install appeared to work correctly, including the "X" configuration(at least the display test, etc appeared to work). Upon booting the system, GRUB executed in full graphics mode, however "X" would not start automaticaly. Manually issuing a startx command causes the message "INIT: Id "x" respawning too fast: disabled for 5 minutes" to be displayed every 5 minutes. After working with tech support for several days trying to correct the problem a manual exec of Xconfigurator was tried with a segmentation fault, always the result of the command. I am attaching the "X" log, the lspci requested, and messages file from install, upgrade, etc Created attachment 60744 [details]
lspci -n output
Created attachment 60745 [details]
strace of Xconfigurator
Created attachment 60746 [details]
XFree86.0.log
Created attachment 60747 [details]
/etc/X11/XF86Config
Created attachment 60748 [details]
install log
Created attachment 60749 [details]
last upgrade log
have not located any files spit out by Xconfigurator. Just one more.... /etc/X11/XF86Config-4 ... anaconda and Xconfigurator write that one. Do not believe /etc/X11/XF86Config-4 exists, will confirm later this pm. /etc/X11/XF86Config-4 does not exist. At what moment does Xconfigurator segfaults? At the beginning? Would you mind running it through gdb? 1. Failure of Xconfigurator occurs 15-20 seconds after selecting "OK" on the initial screen. No information is displayed except for the message "Segmentation fault". 2. I have never used gdb before, can you give me some direction? $ gdb Xconfigurator (gdb) r After it crashes... (gdb) bt Don't type $ and (gdb), these are prompts. 'r' means 'run' 'bt' means 'backtrace' (gdb) r Program received signal SIGSEGV, Segmentation fault. 0x400ddd07 in strlen () from /lib/libc.so.6ce (gdb) bt #0 0x400ddd07 in strlen() from /lib/libc/so.6 #1 0x0804e3fa in carddb_configuration () #2 0x08053c50 in main () #3 0x4007b0c4 in __libc_start_main from /lib/libc.so.6 Hmm. SEGV in strlen() seems to suggest it is being passed NULL or some garbage. Now that you masterize gdb, can you start it again with: $ export LD_PRELOAD=/usr/lib/libefence.so.0 $ gdb Xconfigurator and etc... You may have to install ElectricFence, for this. It will help for telling us where the segfault really occurs. ElectricFence? Yes, a debugging tool in the RedHat distribution. results using ElectricFence are identical with previous, except for address. Any thing I should do? Could you recompile Xconfigurator with the debbuging flag -g ? It would be useful to know at where it segfaults. Have identical bug....... platform HP Vectra 166mHx 64mbt install from scratch same problem, please notify when corrected RH 7.3 - new install, S3 775 2mb EDO, S3 Trio 64v2/dx Open Service Request 210904 The problem is when DRIVER is not given in the database /usr/X11R6/lib/X11/Cards (or /usr/share/hwdata/Cards, I don't know which one is actually used). Example: for dweeks the relevant part is: # S3 Trio64V2 # Commented out the DRIVER line since it is not valid as of 4.2.0 NAME S3 Trio64V2 (generic) CHIPSET S3 Trio64V2 SERVER S3 #DRIVER s3 NOCLOCKPROBE #UNSUPPORTED Note that hwdata should certainly be updated because officially, this chipset _is_ supported by XFree86: http://www.xfree86.org/4.2.0/Status28.html#28 "4.2.0: Support (accelerated) for ..., Trio64V2, ..." Dweeks, can you uncomment #DRIVER s3 in /usr/X11R6/lib/X11/Cards and /usr/share/hwdata/Cards and tell us if it works? Other participants can also play if they find their hardware in the list. And now, the bug in Xconfigurator-4.10.7-3: Xconfigurator.c:1928 if(card[i].driver){ driver_name = strdup(card[i].driver); if(!(card[i].server)) read_card=strdup("None"); if((card[i].flags & UNSUPPORTED) && !preferxf4 ){ preferxf3=1; } } card_selected = i; If no driver is defined in the database, then driver_name remains to NULL. And later: Xconfigurator.c:2007 driver = alloca (strlen(driver_name) + strlen(_(" (Not used by default)")) + 1); which segfaults at the first strlen(). Btw: Xconfigurator has disappeared from rawhide (??) I checked XFree86 official sources and for the S3 Trio64V2 it is: # S3 Trio64V2 NAME S3 Trio64V2 (generic) SERVER S3 DRIVER vga UNSUPPORTED NOCLOCKPROBE The XFree86 official sources contains an out of date and completely
unmaintained Cards database.
Our Cards file should have had the "SERVER" line commented out instead
of the DRIVER line. Oops. Fixed in CVS, and will be in rawhide soon.
It is set to the "s3" driver. If that driver does not work, try
the "vesa" driver, and report back here, reopening the bug. If "vesa" does
not work, try "vga". Let me know your results and I will change the
default accordingly.
Also, for the record..
>Note that hwdata should certainly be updated because officially, this chipset
>_is_ supported by XFree86: http://www.xfree86.org/4.2.0/Status28.html#28
>"4.2.0: Support (accelerated) for ..., Trio64V2, ..."
That would be all fine and dandy if there was ONE card called Trio64V2,
and only one card. There isn't however. There are a plethora of cards
called that, all of which are slightly different, use different RAMDACs
etc. Only SOME of them are supported, not all of them.
If you use the s3 driver and it works, then your card is supported by
the driver. Submit the output of "lspci -vvn" and also "lspci -vv"
and a special entry for your specific card will be added to override
the default.
If "s3" driver does not work, then use "vesa" then "vga" as described
above. Finally, if no XFree86 4.2.0 driver works - the card is not
supported and will not be fixed, because we do not have 5000 S3 cards
lying around, nor the documentation for them.
Closing bug as fixed in RAWHIDE hwdata package, which will appear sometime
this week.
.:
dweeks: I have no idea what "Open Service Request 210904" is refering to, however if it is some Red Hat tech support ticket number or somesuch it is useless to me. Red Hat engineers do not have access to tech support ticket issues. All bug report details are tracked solely in bugzilla and must not refer to outside alternate ticket systems, etc.. I had a closer look at how data from 'Cards' were processed and I may be wrong in my analisis. Line 2007 from Xconfigurator.c is in fact never reached since no flags 'UNSUPPORTED' are set. So there is a segfault that remains mysterious to me... |