Bug 98687 - Applications crash with -fstack-check on compile
Applications crash with -fstack-check on compile
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
2
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-07-07 11:33 EDT by Sean Bruno
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-07 10:30:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sean Bruno 2003-07-07 11:33:57 EDT
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 15:14:03 EDT
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 05:46:25 EDT
Same in FC2 (gcc-3.3.3-7).
Comment 3 Alan Cox 2004-06-21 11:47:10 EDT
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 19:53:39 EDT
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 10:30:57 EDT
Yeah, just don't use -fstack-check.

Note You need to log in before you can comment on or make changes to this bug.