From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
I have been troubleshooting an issue with a multi-threaded application
port from Solaris X86 to Linux.
It was randomly dumping core on "main" or other random parts of code.
After hacking on the issue for about a week, I decided to write a little
hello world program and compile it with the same options as my
application. Lo-and-behold it cored in the same manner, randomly and
I then began to pare off flags and includes and libraries until, as if
by magic, it began to work!
It turned out that there is an existing issue all the way back to RH 7.2
with the compile option "-fstack-check" Here is my sample prog:
printf ("Hello World\n");
compile with: gcc -fstack-check -o test
Run the output program up to 10 times. It should core dump at least
once...Is this a bug in the kernel, compiler or standard libs?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Compile any application with the -fstack-check option
2. Run application mulitple times until SegFault occurs
Actual Results: About 1 in 3 attempts generates a seg fault
Expected Results: Application should have run without a problem.
I have posted this item to the devel mailing list as well. On the list, other
people have reported that this is reporduceable and seems to be only applicable
to REDHAT and derivitive distrobutions. It also does not appear to be gcc
gcc generates code that "extends" the stack by touching every page when
extending the stack, but does so by touching data below %esp.
This is not allowed by the kernel (do_page_fault () in arch/i386/mm/fault.c).
The more interesting question is why is the kernel not killed every time.
Same in FC2 (gcc-3.3.3-7).
The kernel expects the compiler either to move esp first or to use
mmap to map anonymous pages over the new pages.
Indeed, the implementation of this feature is completely borked.
As to why this doesn't happen all the time, and why randomly on
FC2, it's due to /proc/sys/kernel/exec-shield-randomize varying
the top of the stack.
My preferred "solution" to this problem is to remove this code
from the compiler. The concept of the compiler generating code
to check for stack overflow doesn't make a whole lot of sense in
a normal Unix environment.
Yeah, just don't use -fstack-check.