Bug 98687

Summary: Applications crash with -fstack-check on compile
Product: [Fedora] Fedora Reporter: Sean Bruno <sean.bruno>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: low    
Version: 2CC: mitr, tao
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-07 14:30:57 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:

Description Sean Bruno 2003-07-07 15:33:57 UTC
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
confusingly.  

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:

int main()
{
                                printf ("Hello World\n");
                                return(0);
}


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):
3.2.2-5

How reproducible:
Sometimes

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.

Additional info:

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
version specific.

Comment 1 Miloslav Trmac 2003-07-07 19:14:03 UTC
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.

Comment 2 Miloslav Trmac 2004-05-19 09:46:25 UTC
Same in FC2 (gcc-3.3.3-7).

Comment 3 Alan Cox 2004-06-21 15:47:10 UTC
The kernel expects the compiler either to move esp first or to use
mmap to map anonymous pages over the new pages.


Comment 4 Richard Henderson 2004-10-03 23:53:39 UTC
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.

Comment 5 Jakub Jelinek 2004-10-07 14:30:57 UTC
Yeah, just don't use -fstack-check.