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:
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
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. Thanks, Mike
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
Forgot to add. To run the test case put in run.sh. Thanks, Mike
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. Thanks, Mike
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.