2

I am facing Segmentation fault issue during source code compilation. I came across few other forums here where upgrading gcc version would help. But i am already in later version than the one mentioned in above forum.

Log:

x86_64-pc-linux-gnu-g++: internal compiler error: Segmentation fault (program /home/comp/sw/tools/unix/hosts/Linux-x86/unix-build/lib/ld-linux.so.2)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

gcc version:-

ktp@compune-lnx-11:~/compiler$ /home/comp/sw/tools/unix/hosts/Linux-x86/targets/Linux-x86_64/gcc-7.3.0as2-2/bin/x86_64-pc-linux-gnu-g++ --version
x86_64-pc-linux-gnu-g++ (GCC) 7.3.0 (altstack)

Weird thing is that issue is intermittent and not seen all the time. Our build system runs build on some random host. I suspect it is related to h/w. I need help how to go further in debugging this issue.

I am sorry that i am not allowed to copy the source here.

273K
  • 29,503
  • 10
  • 41
  • 64
Kiran
  • 75
  • 7
  • In my experience, the most common cause of a segfault in gcc is running out of memory. Check your `ulimit -a` for memory size limits, and `vmstat` for what is happening on the machine that is failing. If it is intermittent it may also be due to bad memory (hardware). – Chris Dodd Feb 25 '23 at 00:58
  • 4
    It's 2023. Why do you work work with `gcc-7`? By now `gcc-13` is released and `gcc-12` is common with many distributions. As you are faced with _an internal compiler error_ maybe switching is something to consider? – Dirk Eddelbuettel Feb 25 '23 at 00:58
  • GCC is up to version 12.... 7.3 is 5 years old. – ChrisMM Feb 25 '23 at 01:00
  • While I feel your pain, there is very little we can do for you without more information. The tough part here is pretty much the only way to know what information is needed in the question is to have already figured out what the problem is. – user4581301 Feb 25 '23 at 01:00
  • @DirkEddelbuettel, Ours is huge code base, And We have many dependent compatibility issues with latest gcc which we are working on fixing them. Until then we have to work on gcc 7. Switching you mean gcc version? – Kiran Feb 25 '23 at 01:10
  • @user4581301, i am not allowed to copy the source here. Sorry about that :( – Kiran Feb 25 '23 at 01:11
  • @kiran You may want to consider that there is not one reputable public project out there that _today_ insists on using `gcc-7`. I understand that workplaces insist on all sorts of weird rituals to celebrate^Hhide the specific local technical debt, but what you bring up as a reason why you "cannot switch" is ... typically seen as a reason to _switch early and often_ to have your code base clean(er). It's an ideal, but many orgs and project manage. Now that won't help you if your local custom insists on `gcc-7` as the chosen one. You have my most sincere sympathies. – Dirk Eddelbuettel Feb 25 '23 at 01:20
  • `how to go further in debugging this issue` Compile gcc with debug and instrumentations and find out where the bug happens. Follow `See for instructions.` and create an MCVE and find the bug on gcc bugzila and refactor your code so that you do not hit that bug. Both of these ways are not worth it, it is more worth just to move to gcc8. – KamilCuk Feb 25 '23 at 01:48
  • 2
    To rule out hardware errors, can you reproduce it on a different computer? – Nate Eldredge Feb 25 '23 at 02:09
  • 1
    How much memory does the failing system have? You can install a later gcc version in a non-standard place (e.g. `/usr/local/bin`). Most people will still use the standard install, but _you_ can modify the build to use the new version. Probably _not_ a HW issue. With a large project, you may be building in parallel. Try `make -j1` (e.g.). When the bug happens, it should be consistently on a given `.c` [or limited list]. When you identify, the problematic `.c` files, compile with `-O0`. Then, comment out portions of the `.c` with (e.g. `#if 0` and `#endif` (vs. `/*` and `*/`) – Craig Estey Feb 25 '23 at 02:10
  • 1
    When you've isolated the problematic `.c` files, modify the build to compile those files with the later gcc and see if the issue goes away. You can then look at the problematic functions and see if they're doing something "funny/unusual". Note that `ld-linux.so.2` is the ELF interpreter (not part of the compiler). Again, how much memory? Do you have a paging/swap disk, so an uncaught `NULL` return from a `malloc` in the compiler will be less likely to occur? Modify the build process so that the compiler is run under `gdb` (or use it on the core file). – Craig Estey Feb 25 '23 at 02:18
  • @CraigEstey, tricky thing is issue is intermittent across different hosts. Unfortunately they are production hosts where users don't have access. But i have my local machine where build is passing. But i would like to repro the issue by putting memory load on my machine to check if i get segmentation fault issue. Is there a way to increase memory load forcefully somehow on my linux host? BTW, I have .ccp file which causes this failure. – Kiran Feb 25 '23 at 05:05

0 Answers0