I googled around but most of what I could find said that segfaults are generally a memory issue.

I've noticed lately that I'll occasionally get a segfault while compiling on my computer. There's no noticeable pattern, just that every now and then a bit of software that I'm trying to compile will segfault on me, even software that I've compiled in the past.

I ran memtest86+, but it showed no issues at all. I run a stock kernel on Slackware, with no modifications to the system other than installing multilib support (which I'm 100% sure is done correctly).

What else could be the issue?

Could it be heat damage?

I was having this problem on a machine that I used to overclock with.

I kept switching out parts trying to figure out what the problem was.

It turned out that there was some damage to the motherboard that resulted in segfaults.

I was getting them even when the system was not hot.

Luckily this was an older board that I replaced and all is good now ( except for the motherboard and the Athlon 64x2-5600 that I used to have in the board when I was overclocking. )

Its possible, but I don't really think that's the problem. Its a laptop, it stays on pretty much 24/7 but its also on a laptop cooling fan most of the time too. It isn't overclocked and I don't do much to push the hardware. I use a temperature gauge widget and it generally stays right at the line between normal and hot. Its also in an air conditioned room 99% of the time.

segfaults are mostly caused by buggy programs, not by hardware. A segfault is when a process tries to access a memory address that doesn't belong to it.

Yet, in my case it certainly was not a software problem. I was having problems compiling gcc and kernels. When I moved the drive to a similar machine, it compiled just fine.

If on another machine with same hard drive compilation works sure it's hardware problem. But if it's a laptop I guess changing the parts is a bit of challenge

That is not correct. Segfaults are almost certainly caused by bugs in software and very unlikely to indicate a hardware problem.

I have seen that a few times myself and never pinned it down, but I did see a noticeable pattern.

I often run multiple copies of the compiler simultaneously, nearly filling physical ram and typically using a small amount of swap. I have seen rare random segfaults in gcc only when doing that. If there is a significant margin of free ram beyond what one or more copies of gcc need, then there is no segfault.

Since I always have lots of free swap space, I'm pretty sure there is no commit limit issue (no memory request from gcc is being rejected by the kernel).

Some programs detect system resource levels (such as physical ram) and adjust their internal algorithms (time space trade off alternatives) to make better use of available resources. A bug in such code would exactly fit the symptoms I saw. But I don't know whether gcc even includes such code. I certainly have not been able to pin down the details.

I also don't know whether the segfault you've seen is related to the one I've seen.

Same software working symptom free on another machine is still not much of an indication that the original problem was hardware. I think a software bug is still a more likely theory.

A program might take a different path based on any detail of the CPU or any resource level that the program cares to check. One path might hit the bug and another not.