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
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
Steps to Reproduce:
1. Find a technique for finding where in the code it is crashing.
2. Reproduce with a innocuous test case
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.
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.
It's past Monday. Have you a reproducer?
Ideally in the form of preprocessed source (.ii file) created with
g++ -save-temps plus the options you used.
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.
Created attachment 99740 [details]
Reproducer for huge table issues
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,
Forgot to add. To run the test case put in run.sh.
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.
I am happy so we can close.
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.