Bug 44851

Cant attach strace output as forms keep asking me to login all the time and each
time it loses the file.
Will email to mharris instead.

Created attachment 21249 [details]
strace output

Still unable to post ltrace output as Bugzilla keeps asking me to log back in
again (yes I have cookies enabled). Here is a gdb stack trace:

#0  0x400ebb5d in __strdup (s=0x3100 <Address 0x3100 out of bounds>)
    at ../sysdeps/i386/i486/bits/string.h:530
#1  0x080630d7 in isapnpNewDevice () at eval.c:41
#2  0x08060d58 in ddcNewDevice () at eval.c:41
#3  0x08056d12 in compareDevice () at eval.c:41
#4  0x0804c68b in strcpy () at ../sysdeps/generic/strcpy.c:31
#5  0x08053f52 in strcpy () at ../sysdeps/generic/strcpy.c:31
#6  0x40082177 in __libc_start_main (main=0x8053240 <strcpy+34532>, argc=1,
    ubp_av=0xbffffa5c, init=0x804a1a4 <_init>, fini=0x80673d0 <_fini>,
    rtld_fini=0x4000e184 <_dl_fini>, stack_end=0xbffffa4c)
    at ../sysdeps/generic/libc-start.c:129

and from end of ltrace output:
strcmp("@H@0001", "@H@0001")                      = 0
strcmp("RTL3000", "RWB1688")                      = -1
strcmp("@H@0001", "@H@0001")                      = 0
strcmp("RTL3000", "CMI0001")                      = 1
strcmp("@H@0001", "@H@0001")                      = 0
strcmp("RTL3000", "RTL3000")                      = 0
free(0x08189e10)                                  = <void>
free(0x08189e00)                                  = <void>
free(0x08189df0)                                  = <void>
free(0x081885e8)                                  = <void>
sysctl(0xbffff048, 2, 0xbffff050, 0xbffff044, 0)  = 0
syscall(103, 8, 0, 1, 0x080749ec)                 = 0
geteuid()                                         = 0
open("/dev/zero", 0, 016331266165)                = 6
mmap(65536, 65536, 7, 18, 6)                      = 65536
open("/dev/mem", 2, 027777767650)                 = 7
mmap(0, 1282, 7, 18, 7)                           = 0
mmap(655360, 393216, 3, 17, 7)                    = 655360
memmove(0x08074a6c, 0x08074a68, 4, 0, 0xbfffef98) = 0x08074a6c
memmove(0x08074a70, 0x08074a6c, 4, 0, 0xbfffef98) = 0x08074a70
memset(0x08074e8c, '\000', 160)                   = 0x08074e8c
memmove(0x08074a74, 0x08074a70, 4, 0x0806418d, 1) = 0x08074a74
memset(0x00011010, '\000', 256)                   = 0x00011010
iopl(3, 0, 256, 0x08062fd0, 0x081013a8)           = 0
ioperm(0, 1024, 1, 0x08062fd0, 0x081013a8)        = 0
memset(0x08074e8c, '\000', 84)                    = 0x08074e8c
malloc(512)                                       = 0x081885e8
memcpy(0x081885e8, "VESA", 512)                   = 0x081885e8
__strdup(12544, 69648, 512, 0x08062fd0, 0x081013a8 <unfinished ...>
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

Hmm.  Are you using a stock Red Hat kernel, or a homemade one?
If the latter, just for a debugging datapoint can you try using
the Red Hat kernel?

Also are you sure the core was from Xconfigurator and not kudzu?

I am using a stock RH 2.4.3-12 kernel and yes it is from Xconfigurator...

root# file /core
/core: ELF 32-bit LSB core file of 'Xconfigurator' (signal 11), Intel 80386,
version 1, from 'Xconfigurator'

Same seg fault problem  happens to me too. Now, I am not a sysadmin or a kernel programmer,
just a plain end user, so the problem may be trivial; nonetheless, here are full details:

1) A new system with a Duron CPU and a PC Chips M810 MLR motherboard, on a SiS 730 chipset.
I know that SiS  730 is not explicitly supported by XFree86 yet, but I've read elsewhere that
LINUX treats it much like 630, so I decided to give a try.

2) Installed RedHat 7.1 from a boxed CD set, but skipped configuring X Server. ( I skipped it because
the suggested default date looked rather nonsensical, viz. SiS 630 with 1 MB of memory; when I suggested
8 MB, and tried to use the "TEST" button, I got a nice screen picture with a "can you see this text?"
prompt, but after clicking on the "Yes" button I ended up with a screen all messed up. So I decided
to install LINUX first, and to configure X later)

3) LINUX runs just fine in text mode; now's the  time to configure X Windows! 
SuperProbe, indeed, tells me that I have SiS 630 chipset with 16M; fine by me. 

4) I run XConfigurator. Click OK on the welcome screen. The Probe screen comes up, tells me this:
    PCI ENtry: SiS 630
   XServer: XF86_SVGA
   XFree4 driver: (default)
I click on "OK", and XConfigurator dies with Segmentation fault.

I try to run it again and again, but every time it ends up with seg fault. Sometimes it
happens when I click on "OK" in the Welcome screen, sometimes in one of the later
screens, but the end result is the same.

5) I try to run xf86config instead; give sensible answers to all questions, and end up
with a new, sensibly (to me) looking /etc/X11/XF86Config. But when I try to run "startx",
I got messages about syntax errors in the XF86Config file. The first one is 
about the 'Subsection "extmod"' line inside 'Section "Module"' ; the message says 
"Module section keyword expected".  Am not sure what goes on -- perhaps
xf86config produces a config file in a somewhat different syntax from what startx
(well, initx actually) expects? May the two programs on the CD have come from
different versions of XFree somehow? (Indeed: "man xf86config" mentions
"XFree86 Version 4.0.2", while the output from startx mentions "XFree86 ver 3.3.6a".)

I had the same problems during install as well. The X part of the install detected a 630, I said OK , the display came up fine, hit OK
and that the screen went nuts, box hung. I have also have general instability on this hardware under linux. Machine freezes. 

I had the same problem.  I also have the Sis 630 video hardware.  I got past 
the problem by running Xconfigurator with the -noddcprobe option.  When I 
specified that option, wala, no core dump.  I got through the config, wrote my 
file, and X works great.

*** Bug 52060 has been marked as a duplicate of this bug. ***

jwilson, can you please attach the entire output of ltrace?
If it is over 100k, please compress, if compressed if it is over
a meg, email it to me.  I don't have access to this chip, and
I need to see more ltrace...

Actually, can anyone at all do the ltrace...

I have confirmed this same problem on the Asus A7S-VM motherboard with the 
SiS730 chipset.  How do I get the ltrace output for this?

rhealy: Regarding "I have also have general instability on this 
hardware under linux."
Are you seeing DMA errors, segmentation faults or kernel oopses?  If so, try 
setting your BIOS to 100MHz RAM rather than 133 and see if that clears up 
stability problems.  (I'm currently confirming this on Asus A7VI-VM.  Will file 
kernel Bugzilla report tomorrow.)

I have generated an ltrace output and will email directly to mharris
(it is 1.2mb bzip'd)

What's going on with this bug?  mharris, do you need my ltrace output too?

I followed your directions, but both running ltrace and connecting ltrace to 
the Xconfigurator process right before the segmentation fault results in a tiny 
text file containing nothing useful.

ltrace Xconfigurator & > output.txt

Resulted in a tiny text file with no useful information. 

jwilson, what did you use at the command line to get your ltrace to output to a 
text file?

Warren - what's going on with this bug is absolutely nothing currently.
I do not have SiS630 hardware available for testing/debugging purposes,
and the provided info, while necessary, hasn't been enough to find the
problem whatever it may be in the code.

Also note that you've said you've got an SiS730 - which is not supported
at all by XFree86.

Since the original files weren't attached to bugzilla, I no longer have
the emails, nor the files, and hence lost the only information provided
to debug the problem.

I'm afraid the problem probably won't be fixed until I obtain SiS630
hardware or someone who has it can debug it and provide a patch to
fix the problem.  I'm defering this bug until I have hardware to
debug with.

Xconfigurator is now obsolete and replaced by redhat-config-xfree86
in rawhide.

If anyone who has this problem can debug/fix it and produce a patch, feel
free to reopen the bug report and attach the patch and I will apply it to
Xconfigurator CVS.  It'll then be released in any future erratum that
we release.