Hide Forgot
Description of problem: When attempting to re-compile any existing product that compiled under Fedora Core 6 (test 4/pre-final), things would compile to completion without error. Now when attempting to compile things like running "make menuconfig" on the kernel, mplayer, or NVidia's kernel module (I know you guys don't support it, I'm just addding it FYI), there is an internal compiler error which looks like a segmentation fault. I've ran strace on it, but I don't understand what I'm not familiar enough to know exactly what is going it. It seems that there is something that occurs with a memory copy or allocation. Version-Release number of selected component (if applicable): Kernel 2.6.18-2798-1.fc6 Gcc version 4.1.1 Glibc version 2.5-3 How reproducible: Very reproducible. Got a confirmation post from Steve Grubb (sgrubb@redhat.com) that he is seeing something similar. Steps to Reproduce: 1. Make sure the versions of code are installed above on x86_64 machine. 2. cd to /usr/src/kernels/2.6.18-1.2798.fc6-x86_64 (have kernel-devel installed) 3. make menuconfig Actual results: [root@jaguar 2.6.18-1.2798.fc6-x86_64]# make menuconfig HOSTCC scripts/kconfig/conf.o scripts/kconfig/conf.c: In function âstripâ: scripts/kconfig/conf.c:58: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugzilla.redhat.com/bugzilla> for instructions. Preprocessed source stored into /tmp/cc603YAn.out file, please attach this to your bugreport. make[1]: *** [scripts/kconfig/conf.o] Error 1 make: *** [menuconfig] Error 2 Expected results: Entered the menuconfig curses screeen. Additional info: So I used the kernel as an example, but it occurs with other programs that would compile before but not now: Nvidia driver and mplayer are the two example /tmp/cc<hash>.out files that I've included.
Created attachment 138973 [details] Bzip2 tar file of the /tmp/cc<hash>.out files from compiling things
Can't reproduce this with gcc-4.1.1-30 nor any other gcc I have around. On your box, is there anything gcc doesn't segfault on? Some of the dumps are really trivial one liners, if the bug was in gcc, it wouldn't definitely pass its tens thousands of tests run during the build. So, I'd say either you have hardware problems, or some kernel bug.
I created a simple make file and c program to show that the basics work: <hello.c> #include <stdio.h> int main() { printf("Hello World\n"); return(0); } </hello.c> <Makefile> # Make file for Hello.c hello.o: $(CC) $(CFLAGS) -o hello.o hello.c clean: rm hello.o </Makefile> I'll try a diagnostic CD to see if something is going bad with my processor, memory, or drives. If you have any other tests that I could try that may help pinpoint this issue, let me know.
There is another report of similar problems and that is even on another architecture. See: https://www.redhat.com/archives/fedora-test-list/2006-October/msg00649.html Unfortunately this note is also remarkably short on essential details; in particular it also does not mention what _really_ bombs out. Some guesses about possibly reasons based on past experiences: - out of space on /tmp - something messed up in a file system used by /tmp - gcc optimizer spooked by something (not necessarily easy to reproduce) Still I did not run into gcc exceptions for reasons like above for quite a while now.
Looks like I'm having hardware problems. Used two different cpu stress tests from ubcd 3.4 and both came up with errors. Popped my case open and found that a fan had stopped working, so I'll be buying a new MB and CPU soon. Thanks for your time. Jonathan