How to resolve issue with gcc internal compiler error: Segmentation fault - c

I have written a "hello world" C code:
#include<stdio.h>
int main()
{
printf("hello world");
return 0;
}
When running the below command:
gcc main.c -o main
I am getting below error:
main.c: In function ‘main’:
main.c:8:1: internal compiler error: Segmentation fault
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
Below is the output of lsb_release -a:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.6 LTS
Release: 18.04
Codename: bionic
gcc version:
gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
How can I resolve this issue?
Edit
I compiled the code with g++:
g++ main.c -o main
and it worked fine with no errors.

Given your GCC version of gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 this is an Ubuntu problem. Ubuntu 18.04 was released 4 1/2 years ago, and the odds of this being a problem with GCC itself are rather slim. As #thebusybee noted in the comments, this is almost certainly something caused by some problem with the compiler installation.
What you need to do is find out what's wrong with your Ubuntu GCC installation. First, make sure you're not doing something that causes the problem. Environment variables such as LD_PRELOAD (or any of the LD_* envvals) can effect GCC. There's also many other envvals that can.
Since you post that you can't upgrade the OS, that implies you're working in an organization with separate system administrator(s) that control the OS installation. So if GCC's failing is not caused by something you're doing this is really the system administrators' problem to solve. If your organization gives them control of the OS installation, that includes everything that they control and you're unable to change, such as the OS-supplied GCC installation here.
What you can do to keep working:
First, make sure you're not doing something to cause the problem
Check your environment for any LD_* envvals such as LD_PRELOAD. Make sure they're not causing the problem.
Check for other envvals that could effect GCC.
Install a version of GCC somewhere you are allowed to modify,
such as your home directory
Modify your PATH and other necessary envvals to used your local GCC copy
Use your organization's process(es) to create a trouble ticket to have your system administrator(s) investigate and repair your system. If you're not allowed to modify it, it's their problem.
If you have the time, you add something like the -v verbose flag or use GCC's Developer Options such as -freport-bug to try to figure out what's wrong with your system and help your system administrator(s) in solving the real problem here.

Related

GCOV Profiling: ".gcda:Version mismatch"

I'm currently compiling sources using --coverage, with GCC. The generated .gcno files (and the instrumented libraries) are to be packed in a RPM and the code coverage evaluated on another, target platform.
Now, I'm having a problem getting the coverage data, because when I run the programs calling the instrumented code, I get messages telling me that I have a version mismatch. They look like:
".gcda:Version mismatch - expected A85R got B12R"
Now, I've seen this question: GCOV Version mismatch - expected 700e got 408R which says I must use the same toolchain when compiling and when executing the code.
I'm compiling using gcc 11.2.1, and gcov --version says the same thing, on the source platform.
On the target platform, gcc --version and gcov --version both give that very same version number.
The compiling and the testing is done on the same "physical" machine, but on different Docker containers. On both of them, the GCC version and gcov version are the same
I've done further testing: even on the Docker container where we compile, we cannot run the coverage, and get the same error. Or, to be more precise, when compiled using gcc 11, it will say "version mismatch". However, when compiled using gcc 8.5, it works.
The setup is that we have the GCC 11 toolset, which requires gcc 8.5 to install. By default, gcc 8.5 is enabled, and you have to use a script (provided by the gcc 11 toolset) to enable the later. That script updates different variables, like the PATH, LIBRARY_PATH, etc., to look at GCC 11 first.
However, I'm pretty sure it doesn't upgrade the libc.so library, and that it's the cause of the problem: I compiled two of our simplest libs (each of them having no dependencies whatsoever, except libc) with gcc 11, in coverage mode. Then I compiled a simple test program, without coverage, calling some functions from the two instrumented libs. I checked (with elfread -d), the program only links to these two libs (and libc).
Calling this test program while on the compilation container results in the Version mismatch error, which would lead me to conclude that our libc.so isn't compatible with gcc 11.
I wonder if there is a way to get a "native" gcc 11, instead of a "toolkit" package which has to be installed over a gcc 8.5 (my colleague in charge of creating the Docker containers tells me that for gcc 9 and above, there are only "toolkit" packages, requiring gcc 8.5 to install).
Our target architecture runs on Rocky Linux, and I think our development architecture is a Redhat, if it has any importance here.

clang does not generate gdb symbols on windows [duplicate]

When using clang v8.0.0 on Windows (from llvm prebuilt binaries) with -g or -gline-tables-only source map tables are not being picked up by gdb or lldb debuggers.
Upon including -g flag file grows in size (which is to be expected) yet neither gdb nor lldb pickes the source up
When compiled with gcc though (with -g flag) source files are detected by debugger.
I have tried running the same command (clang -g <codefile>) on macOS High Sierra (clang -v says it is Apple LLVM version 10.0.0 (clang-1000/10.44.4)) where there source files are being picked up by lldb. So I guessed it is localized to my windows instance or llvm for windows build.
P.S. output of clang -v on windows:
clang version 8.0.0 (tags/RELEASE_800/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
On Windows, Clang is not self-sufficient (at least not the official binaries). You need to have either GCC or MSVC installed for it to function.
As Target: x86_64-pc-windows-msvc indicates, by default your Clang is operating in some kind of MSVC-compatible mode. From what I gathered, it means using the standard library and other libraries provided by your MSVC installation, and presumably generating debug info in some MSVC-specific format.
Add --target=x86_64-w64-windows-gnu to build in GCC-compatible mode. (If you're building for 32 bits rather than 64, replace x86_64 with i686). This will make Clang use headers & libraries provided by your GCC installation, and debug info should be generated in a GCC-compatible way. I'm able to debug resulting binaries with MSYS2's GDB (and that's also where my GCC installation comes from).
If you only have GCC installed and not MSVC, you still must use this flag.
How do I know this is the right --target? This is what MSYS2's Clang uses, and I assume they know what they're doing. If you don't want to type this flag every time, you can replace the official Clang with MSYS2's one, but I'm not sure if it's the best idea.
(I think they used to provide some patches to increase compatibility with MinGW, but now the official binaries work equally well, except for the need to specify the target. Also, last time I checked their binary distribution was several GB larger, due to their inability to get dynamic linking to work. Also some of the versions they provided were prone to crashing. All those problems come from them building their Clang with MinGW, which Clang doesn't seem to support very well out of the box. In their defence, they're actively maintaining their distribution, and I think they even ship libc++ for Windows, which the official distribution doesn't do.)

Python installation cannot run C compiled programs on Debian 9

I'm trying to install Python 3.7 on my Linux machine, but it's telling me it's unable to run C compiled programs:
root#kvm-RPJared2:~/Python-3.7.3# sudo ./configure --enable-optimizations
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for python3.7... no
checking for python3... python3
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... checking for --without-gcc... no
checking for --with-icc... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in `/root/Python-3.7.3':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
root#kvm-RPJared2:~/Python-3.7.3# gcc --version
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
As you can see, I already have GCC installed, so I'm a bit lost on how to solve this issue.
Edit: I've already tried to download directly from git using apt-get, but the program is running into trouble with invalidated GPG keys. I've also tried using make as a different su, and that runs into the same error as I've shown above. If anyone has answers to either the apt-get issue (--allow-inauthenticated hasn't worked either) or the error I've pasted above, please help me out!

Machine/compiler dependent segfault with c code

I am trying to run a parallel code (numerical simulation) on a Linux machine. I have tested the code configuration on my laptop (OSX) and all works fine. When I ship to the larger (Linux) machine it segfaults on the first timestep.
I didn't write the code and don't want to get into debugging it. I am hoping that it may be possible to solve the problem with a different compiler or flags.
On my laptop (OSX) I have the code running with the default compiler.
cc --version
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.5.0
On the Linux machine that I work on, I am using
cc --version
cc (Ubuntu 4.9.4-2ubuntu1~14.04.1) 4.9.4
I have tried both 4.9.4 and 4.8.4 on the Linux machine, and both give the same segfault.
My Makefile sets the following directives:
CFLAGS = -O3
LDFLAGS = -I`pwd` -I$(SRCDIR) -I/usr/bin/include -I/usr/include/mpi
LIBFLAGS = -lm -lnetcdf -lmpi -L/usr/bin/lib
I know this is a shot in the dark, but if anyone has a suggestion for a change I could try to get this working on the linux machine I would be most grateful. In case it's not obvious to you already, I am a mere regular scientist, not a computer scientist, so most of this is black magic to me.
Thanks.
I didn't write the code and don't want to get into debugging it.
Well, if you refuse to help yourself, you'll have to bribe someone else to do it for you.
I am hoping that it may be possible to solve the problem with a different compiler or flags.
It may well be possible, but finding the right flags requires understanding the problem in the first place.
Otherwise, you are trying to program by coincidence, and that rarely leads to success.

How can I use debug version of glibc to build a program?

i want to debug something in glibc, so i want to use a debug version of glibc to build the program.
if i just use "gcc -o test test.c" to build the program,
apt-get install libc6-dbg
apt-get source libc6-dev
when i was debugging the programs,some val is told that it is optimized. and EIP is always jump back.
how can i debug the debug version of glibc.
Caveat: I use fedora but it has a similar mechanism.
The debug package downloads an additional file that has the debug information you would get if you compiled with -g for glibc.
But, this package matches the standard build which is built with optimization (e.g. -O2).
It's the optimization that is causing the behavior you're seeing. So, the gdb "coverage" will be spotty.
What you want is a glibc version that is built with -gdwarf-2 and -O0. AFAIK, you'll have to get that by building glibc yourself from the source.
You'll probably have to run the configure script and select the -g and -O options for the build. Then, run make. The exact details should be in the source documentation [or online] somewhere.
Then, you'll have to [forcibly] link your program against the built-from-source version.

Resources