Bug 114519 - g++: Internal error: segmentation fault (program cc1plus)
g++: Internal error: segmentation fault (program cc1plus)
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: gcc (Show other bugs)
2.1
ia64 Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-28 19:46 EST by Michael Chynoweth
Modified: 2012-06-20 09:24 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 09:24:14 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)
Reproducer for huge table issues (4.27 KB, application/zip)
2004-04-28 12:43 EDT, Michael Chynoweth
no flags Details

  None (edit)
Description Michael Chynoweth 2004-01-28 19:46:10 EST
Description of problem:
We are having a segmentatoin fault in cc1plus.  Occurs even when 
compiling in debug /Od or with /O2.

Version-Release number of selected component (if applicable):
Red Hat Linux 7.2 2.96-124.7.2

How reproducible:
If I can figure out where it is crashing while compiling the source I 
could probably create a safe reproducer to send out.  I just need to 
find out some techniques for finding compile time crashes with the 
gcc compiler.

Steps to Reproduce:
1.  Find a technique for finding where in the code it is crashing.
2.  Reproduce with a innocuous test case
3.  
  
Actual results:


Expected results:


Additional info:
Comment 1 Michael Chynoweth 2004-01-29 14:11:49 EST
Hi Jed,

I threw the -Q option on the source files and was able to tell that 
it is crashing after a destructor to a template.  The most recent 
function is __tcf_1.  This is not a function within the source so I 
am not sure what this function is.

Thanks,

Mike
Comment 2 Michael Chynoweth 2004-01-31 14:05:11 EST
We have narrowed down this bug.  It looks like the crash in gcc 
compile is due to a compilation of a table with ~100,000 entries.  I 
will have a reproducer by Monday.
Comment 3 Suzanne Hillman 2004-02-06 13:33:14 EST
It's past Monday. Have you a reproducer?
Comment 4 Jakub Jelinek 2004-02-09 10:58:32 EST
Ideally in the form of preprocessed source (.ii file) created with
g++ -save-temps plus the options you used.
Comment 5 Michael Chynoweth 2004-02-09 11:26:39 EST
Unfortunately I cannot share source in this case.  I tried to create 
a good reproducer and it failed to recreate the crash.  I have 
started to split up the large table to determine when it crashes.  
Give me 1.5 weeks to get a good reproducer.

Thanks,

Mike
Comment 7 Michael Chynoweth 2004-04-28 12:43:16 EDT
Created attachment 99740 [details]
Reproducer for huge table issues

Hi RedHat,

Here is a reproducer for the huge table problem.  I apologize this took me so
long...I had some other items to look into.

It looks like the problem is that gcc is overrunning its stack when compiling
this huge table.  If I boost up the limit of stack to a ridiculously high value
(ulimit -s 262144), the issue goes away.

I included a simple test case just incase you wanted to put in some meaningful
error here, but from my side you can go ahead and close this bug.

Version is the same:  gcc-c++-2.96-124.7.2

Thanks for taking a look into this,

Mike
Comment 8 Michael Chynoweth 2004-04-28 12:46:17 EDT
Forgot to add.  To run the test case put in run.sh.

Thanks,

Mike
Comment 9 Richard Henderson 2004-10-04 14:36:09 EDT
For the record, RHEL3 with gcc 3.2.3-24 *just* compiles this test case
with the default 10MB stack.  Either that or ulimit -s 9216 has other
more serious process creation issues.

Stack overflow conditions are notoriously difficult to recover from in
any friendly way.  For a project in the support state of gcc 2.96, I
don't think we want to get into the kind of churn that would be required
in order to fix or diagnose this condition in anything like a reliable
way.  So if Mike is happy increasing stack size, then I'm happy, and
we can close.
Comment 10 Michael Chynoweth 2004-10-05 16:36:14 EDT
I am happy so we can close.

Thanks,

Mike
Comment 11 Jiri Pallich 2012-06-20 09:24:14 EDT
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

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