Bug 654130
| Summary: | A small simple program can reliably cause the compiler to crash | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Eric Hopper <eric-bugs2> |
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 14 | CC: | aravindvijayan224185, brendan.jones.it, jakub |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-12-28 05:03:47 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: | |||
Thank you for the bug report. Unfortunately, without a stack trace from the crash it is impossible to determine what caused the crash. Please see http://fedoraproject.org/wiki/StackTraces for more information about getting a useful stack trace with debugging symbols. Even if you cannot reproduce this crash at will, you can prepare your system now to produce a good stack trace the next time you experience the crash. Thank you. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers (In reply to comment #1) > Thank you for the bug report. Unfortunately, without a stack trace from the > crash it is impossible to determine what caused the crash. *raises eyebrows* Really now. Do you mean to say that the simple program I provided doesn't crash the compiler for you? It's done it for every version of gcc4 I've tossed its way. I suppose I'll go get a stack trace just to be bureaucratically correct. The c#1 comment doesn't make any sense for the compiler, for the compiler what matters is just a reproduceable (usually preprocessed, but in this case it is not needed) source plus options and gcc version/architecture.
/* { dg-do compile } */
/* { dg-options "-O2" } */
#define S1 " "
#define S2 S1 S1 S1 S1 S1 S1 S1 S1 S1 S1
#define S3 S2 S2 S2 S2 S2 S2 S2 S2 S2 S2
#define S4 S3 S3 S3 S3 S3 S3 S3 S3 S3 S3
#define S5 S4 S4 S4 S4 S4 S4 S4 S4 S4 S4
#define S6 S5 S5 S5 S5 S5 S5 S5 S5 S5 S5
#define S7 S6 S6 S6 S6 S6 S6 S6 S6 S6 S6
void
foo (void)
{
__builtin_printf (S7 "\n");
}
The problem is just that the string literal is temporarily duped using alloca, which for > 10MB strings doesn't work for the default stack limits. You can of course run it with a larger ulimit -s and it will work.
(In reply to comment #3) > The problem is just that the string literal is temporarily duped using alloca, > which for > 10MB strings doesn't work for the default stack limits. You can of > course run it with a larger ulimit -s and it will work. Ahh, that makes sense. And it also makes sense why the compiler can't produce a better diagnostic. There's no really good way to handle running out of stack space or even knowing that it happen in C. I was worried that I found some kind of interesting and odd bug that would bite people who were writing programs less pathological than mine. Thank you for your bug report.
We are sorry, but the Fedora Project is no longer releasing bug fixes or any other updates for this version of Fedora. This bug will be set to CLOSED:WONTFIX to reflect this, but please reopen it if the problem persists after upgrading to the latest version of Fedora, which is available from:
http://fedoraproject.org/get-fedora
--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
|
This small simple program: ---------snip here---------- #include <stdio.h> #define str(a) #a #define str1(a) str(a) #define str2(a) str1(str1(a)) #define str3(a) str1(str2(a)) #define str4(a) str1(str3(a)) #define str5(a) str1(str4(a)) #define str6(a) str1(str5(a)) #define str7(a) str1(str6(a)) #define str8(a) str1(str7(a)) #define str9(a) str1(str8(a)) #define str10(a) str1(str9(a)) #define str11(a) str1(str10(a)) #define str12(a) str1(str11(a)) #define str13(a) str1(str12(a)) #define str14(a) str1(str13(a)) #define str15(a) str1(str14(a)) #define str16(a) str1(str15(a)) #define str17(a) str1(str16(a)) #define str18(a) str1(str17(a)) #define str19(a) str1(str18(a)) #define str20(a) str1(str19(a)) #define str21(a) str1(str20(a)) #define str22(a) str1(str21(a)) #define str23(a) str1(str22(a)) #define str24(a) str1(str23(a)) #define str25(a) str1(str24(a)) #define str26(a) str1(str25(a)) #define str27(a) str1(str26(a)) #define str28(a) str1(str27(a)) #define str29(a) str1(str28(a)) #define str30(a) str1(str29(a)) int main(int argc, char *argv[]) { printf(str22("This is a long string with a quoted \" in it.") "\n"); return 0; } ---------snip here---------- can reliably crash the compiler. If I change the 'str22' in the printf statement to 'str21' it succeeds and produces approximately what I expect it to. If I change it to 'str28' it consumes an enormous amounts of memory, thrashes a bit, then crashes. If I change it to 'str30' it consumes enormous amounts of memory, thrashes, and gives me a helpful out-of-memory error. I expect the memory usage and the thrashing. I do not expect the crashing. Here is the crash message: $ gcc -O3 -c expand.c gcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See <http://bugzilla.redhat.com/bugzilla> for instructions. Here is the version of the compiler that I'm using: $ gcc --version gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ rpm -q gcc gcc-4.5.1-4.fc14.x86_64