Bug 654130 - A small simple program can reliably cause the compiler to crash
Summary: A small simple program can reliably cause the compiler to crash
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 14
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-16 23:24 UTC by Eric Hopper
Modified: 2011-12-28 05:03 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-28 05:03:47 UTC


Attachments (Terms of Use)

Description Eric Hopper 2010-11-16 23:24:43 UTC
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

Comment 1 Brendan Jones 2010-11-17 13:25:10 UTC
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

Comment 2 Eric Hopper 2010-11-17 14:38:13 UTC
(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.

Comment 3 Jakub Jelinek 2010-11-17 15:00:12 UTC
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.

Comment 4 Eric Hopper 2010-11-17 15:26:16 UTC
(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.

Comment 5 Aravind vijayan 2011-12-28 05:03:47 UTC
    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


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