Extra unexpected stack frame in the backtrace of a C program on macos M1

[jaikiran]

I'm not sure if this is the right place to report this, but looking at the Clang and LLVM website, I thought of raising it here.

Consider the following trivial code, which intentionally is written to generate a segmentation fault when the program is run. Line number 26 is where it intentionally writes to a uninitialized reference to trigger the crash. The program is compiled with -g flag with source level debug information enabled.

#include <stdio.h>

struct Bar {
    int i;
};

typedef struct Bar Bar_t;

struct Foo {
    Bar_t **bar;
};

typedef struct Foo Foo_t;

void b() {
    printf("Entered b\n");
}

void a() {

    b();

    Foo_t *s = NULL;
    s->bar[0] = NULL;
}

int main() {
    printf("Entered main\n");
    a();
}

Compiled as follows:

cc -g -o crash.o crash.c

Then run as:

./crash.o

When this is run on macOS M1 system the program crashes and generates a crash report which contains the backtrace. The backtrace is what looks odd:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   crash.o                                0x10052ff58 a + 24 (crash.c:26)
1   crash.o                                0x10052ff50 a + 16 (crash.c:23)
2   crash.o                                0x10052ff84 main + 24 (crash.c:31)
3   dyld                                   0x191aebe50 start + 2544

Notice the stack frame numbered 1 in that backtrace. I don't understand why that is listed in the backtrace. That line 23 represents a call to method b() from which the code flow has returned back and then moved to line 26 in method a(), which is where the crash occurs. So why is there that extra stack frame in the backtrace? The macOS M1 version and cc version is as follows:

$ sw_vers
ProductName:        macOS
ProductVersion:     13.0.1
BuildVersion:       22A400

$ cc --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.1.0
Thread model: posix

Just to be sure that I am not missing something obvious, I ran this same code on a Linux system (of course recompiling there first) and the backtrace I get there is what I would expect:

(gdb) bt
#0  0x00000000004005b5 in a () at crash.c:26
#1  0x00000000004005da in main () at crash.c:31

Linux and cc version where it works as expected is:

$ uname -a
Linux foo-bar 4.18.0-408.el8.x86_64 #1 SMP Mon Jul 18 17:42:52 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ cc --version
cc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-17)

[jaikiran]

Any thoughts on this one? If this isn't the right place to report this, would anyone have any inputs on where to report this?

[jaikiran]

Hello @Endilll, do you think this issue is something that's relevant for this project? I was unsure when I opened it. If this is not relevant here, then I'll go ahead and close it.

[Endilll]

I'm not an expert on the topics your report is concerned with, but it doesn't strike me as irrelevant for us. But it would be nice if you can reproduce this with trunk or latest release of upstream Clang, since your report is referencing AppleClang 14.