# gcc Internal Compiler Error

## alienjon

I started getting the infamous Internal Compiler Error a little while back.  I didn't think much of it, finding that a re-emerge or syncing my tree the next day (though in retrospect I wonder if it was turning off my computer for a while before trying again) seemed to fix the problem.  Last week the problem wouldn't go away and, after searching on the interwebs, I figured out that this isn't really a problem with GCC so much as a hardware issue.  Correct me if I'm wrong on this, but from what I read it looks like this could be several pieces of hardware (compiler, motherboard, or RAM) however RAM is the typical culprit.  As it only came up while building larger packages I figured, again, that it was RAM because by the time the RAM required to hold larger bits of information came up, that's where something would error.

My build has 32gb of RAM (x4 8gb sticks).  For the sake of testing I ordered my slots 1, 2, 3, and 4 and my RAM modules A, B, C, and D.  I paired them off (A & C, B & D, B & A, and D & A).  In this manner building qtwebkit (though this has happened with GCC and other large builds before) failed with the B & D and D & A tests, making me figure that the D stick is at fault.  I ordered a replacement 8gb stick.  Of course upon arrival I am now emerging just fine without the error.

My question is this: was my testing adequate to identify the RAM as being the culprit (specifically the D stick).  I haven't taken the new RAM out of the packaging, figuring that if the problem goes away I should return it until I'm certain this is the problem (I don't want to spend the money otherwise).  The RAM is new (less than a year old) and the motherboard and processor aren't ancient, but a bit older (I got both at the same time about 2-3 years ago).  I wouldn't expect any of them to be failing from age by this point, so it might well be a defect in something (unless it IS a software error, but elsewhere on the web indicated this wouldn't be the case).

----------

## Keruskerfuerst

You should buy RAM modules from special brands.

I have worked for computer companies, which develop and build computers.

These computers need to be tested carefully.

Even if the computer was build with completly new parts, some computers didn´t work and parts are faulty.

----------

## schorsch_76

The problem could be a overheated CPU, bad or insufficient power supply ...

----------

## alienjon

Thanks for the replies!

 *Keruskerfuerst wrote:*   

> You should buy RAM modules from special brands.

 

I'm not sure what you mean.  The brand I'm using is PNY.

 *schorsch_76 wrote:*   

> The problem could be a overheated CPU, bad or insufficient power supply ...

 

I was wondering about the overheating.  I should make sure the temp modules are all setup and logged somewhere.  At the same time, the problem occurred initially soon after starting the computer (uptime couldn't have been more than an hour or so).  I doubt it's an insufficient power supply, though, the EVGA Supernova 1000W should be more than enough for what I'm running now.  I went a bit overboard (IMO) on the power with plans to eventually add another graphics card.

----------

## Keruskerfuerst

You can buy Kingston hyperX modules.

----------

## schorsch_76

 *alienjon wrote:*   

> Thanks for the replies!
> 
> ...
> 
>  *schorsch_76 wrote:*   The problem could be a overheated CPU, bad or insufficient power supply ... 
> ...

 

Just for your info: During summer i had such an issue on my laptop (Dell L501X with Sandy Bridge i7). I changed the jobs from 12 to 4 and the temperature dropped from 97 °C to 85°C which prevented the internal gcc error. If it is a self assembled system, try to reapply the heat paste between cpu and cooler.

----------

## alienjon

 *Keruskerfuerst wrote:*   

> You can buy Kingston hyperX modules.

 

I'm hoping to not have to replace them all quite yet (or were you thinking only the single replacement one - I understand that keeping the same chip with the same latencies give performance an edge).  I'll definitely keep this in mind, though.  Thanks for the recommendation!

 *schorsch wrote:*   

> Just for your info: During summer i had such an issue on my laptop (Dell L501X with Sandy Bridge i7). I changed the jobs from 12 to 4 and the temperature dropped from 97 °C to 85°C which prevented the internal gcc error. If it is a self assembled system, try to reapply the heat paste between cpu and cooler.

 

Mine's an Intel Core i5-2500 (also Sandy Bridge).  I'll look into keeping tabs on the temp as well.  I may return the new stick for now but reapplying the heat paste is a rather good idea.  Thanks!

----------

## soulsource

Regarding the memory modules I would have done the same (pair them and see which combinations work, and which don't).

About testing though, I'd suggest you to try a dedicated RAM test instead of relying on compiler errors. The classic is memtest86, but there's also the free memtest86+ and if you are a Windows user, you can also get Microsoft's Memory Diagnostics for it (I think with current Windows versions it might even be built into the system itself, but don't quote me on that).

I'd download the memtest86+ ISO image, and run it for several hours (to be really sure that all installed modules are OK let it finish several full passes - memory errors can be nasty, and only show up sporadically, for instance when the discharging of the storage cells is just slightly too fast, so that the voltage at refresh is nearly at a well defined level, or they might depend on module temperature...) with each combination of memory modules.

Should memtest86+ start initially, but crash later, it's a hint that something else, but not the memory, is damaged, that the memory is overheating, or that you have one of those nasty memory issues that only show up sporadically.

As this is the Gentoo forums, you might instead want to build memtest86+ from source. It's available through the portage tree as sys-apps/memtest86+.

----------

## alienjon

 *soulsource wrote:*   

> build memtest86+ from source

 

Whelp, there it is.  The 'I need to kick myself' moment.  I haven't used the tool before, but see it on my laptop (with Ubuntu) everytime I turn it on and should have thought of it.  Only problem is that it isn't working.  As this has become a new issue I'll post in a different thread on that piece.  Thanks for the suggestion.

----------

## alienjon

Quick update: I've got memtest working and am about 23 hours into the run (currently pass 3/4).  The output says no errors yet, but I have 3 notes that read:

```
[Note] RAM may be vulnerable to high frequency row hammer bit flips
```

A search online indicated that this isn't something to be greatly worried about if I'm several passes in, except this note comes up 3 times and I'm currently on pass 3 (making me wonder if it's happened each time).  Correct me if I'm wrong, but I wonder that because this is a 'note' and not an 'error', this may indicate a lesser problem (maybe not one that happens everytime) and would coincide why the error doesn't happen each compile for a larger program.

Should this be the case I think this is enough evidence for me to open up the new RAM (alas, it's still in the shipping package in case I decided to return it) and rerun the test to verify.

----------

## alienjon

Well shoot.  I'm 75% in the second test - about 24 hours (with the new RAM replacing the suspected bad one) and I not only have 2 of the aforementioned warnings, but also an error.

 *Quote:*   

> Test: 13 Addr: 42F585400 Expected: 00000000 Actual: 00008000 CPU: 0

 

I take it that this is evidence that this is not a problem with my RAM, then, but must be with the CPU and/or motherboard?  Anyway I can test more specifically?

----------

## alienjon

Final output

 *Quote:*   

> Test Start Time : 2015-10-11 23:08:09
> 
> Elapsed Time : 39:54:34
> 
> # Tests Passed: 45/48 (93%)
> ...

 

And the next screen

 *Quote:*   

> Test    Errors
> 
> 0    0
> 
> 1    0
> ...

 

----------

## alienjon

So, more than a month later and I'm still having problems.  I ended up swapping out the original 'D' stick of RAM I mentioned in an earlier post and the problem went away for a while - though I also wasn't doing any major builds on my system either for most of that time.  I've recently started upgrading from KDE4 to Plasma 5 and the error has started back up (sometimes with a 'bus error' appended to it).

Now, in all fairness I was having blockage errors (some parts of Plasma 5 are masked/keyworded such that KDE 4 parts (such as kdelibs) is still installed) so I decided to try getting KDE 4 off completely.  In trying to do so I've unmerged several packages, updated keywords/USE flags, and am trying to -uND world and @preserved-rebuild to make sure everything is installed appropriately.  This is where the problem started back up again (and at a rather inconvenient time, as restarting my computer before I get to a certain point will leave me without a graphical environment - not the end of the world, but I don't have much free time to work on my system right now and don't want to be without a working desktop for very long).

I have kept an eye on my temps.  As of my writing this my CPU is the hottest I've seen it at 45 C, and I would imagine well withing operating parameters (though correct me if I'm wrong in that).  I've also not noticed any problems with the system outside of compilations (ie: no lag, crashing, etc...).

Any other thoughts for narrowing down exactly what could be the problem?  My only other thought right now is trying to redo the heat paste (as per schorsch_76's suggestion) however, again, the temps don't seem that bad to me at the moment.

----------

