ASan on Mac arm64 clang only showing stack trace from violating file

[j-p-c]

I asked about this on Stack Overflow thinking it was user error, but I'm thinking it might be a bug.

However, I also note that this is not a supported platform, so I'm prepared for this being a wontfix.

The stack trace only shows those functions that are in the same source file as the function that violated ASan.

New M1 Mac, LLVM installed from Homebrew:

$ /opt/homebrew/opt/llvm/bin/clang --version
Homebrew clang version 13.0.1
Target: arm64-apple-darwin21.5.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin

Simplest repro I could come up with is in the Stack Overflow question above.

I'm happy to try to help debug this, but not currently familiar with the LLVM codebase.

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

[j-p-c]

I've confirmed that this is a bug by comparing with the same commands on the same machine under Rosetta (output attached to the Stack Overflow question above).

[fhahn]

Your reproducer seems to work fine with build from current main. I get:

==44296==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x0001049e3e1c bp 0x00016b41f320 sp 0x00016b41f320 T0)
==44296==The signal is caused by a WRITE memory access.
==44296==Hint: address points to the zero page.
    #0 0x1049e3e1c in bar b2.c:3
    #1 0x1049e3dcc in main b1.c:9
    #2 0x234da8d64  (<unknown module>)
    #3 0xd812fffffffffffc  (<unknown module>)

==44296==Register values:
 x[0] = 0x0000000000000001   x[1] = 0x000000016b41f648   x[2] = 0x000000016b41f658   x[3] = 0x000000016b41f770
 x[4] = 0x0000000000000000   x[5] = 0x0000000000000000   x[6] = 0x0000000000000000   x[7] = 0x0000000000000000
 x[8] = 0x0000000000000000   x[9] = 0x0000000000000002  x[10] = 0x0000000000000000  x[11] = 0x0000000000000002
x[12] = 0x000000016b41f2ea  x[13] = 0x0000000000000001  x[14] = 0x0000000000000001  x[15] = 0x0000000000000001
x[16] = 0x000000000000004a  x[17] = 0x82ca00024c49ea80  x[18] = 0x0000000000000000  x[19] = 0x00000001049f5ce0
x[20] = 0x00000001049e3dc4  x[21] = 0x00000001049f5d00  x[22] = 0x000000016b41f4d0  x[23] = 0x0000000234e1d000
x[24] = 0x0000000248682340  x[25] = 0x0000000000000000  x[26] = 0x0000000000000000  x[27] = 0x0000000000000000
x[28] = 0x0000000000000000     fp = 0x000000016b41f320     lr = 0x00000001049e3dd0     sp = 0x000000016b41f320
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV b2.c:3 in bar
==44296==ABORTING
[1]    44296 abort      ./b.out

Could you try with LLVM 14.0 from Homebrew? I am closing the issue for now, please re-open if it still reproduces with the latest version.

[j-p-c]

I am still getting the bug with the latest LLVM 14.0 (14.0.6_1) from Homebrew.

[j-p-c]

I am unable to re-open this issue.

[fhahn]

Ok, looks like this was fixed after 14.0. It works as expected with a build of current main, but not on the release/14.x branch.

So this should be fixed in the upcoming 15.0 release. It would be great if you could double-check this works as expected once the release candidates are out. Closing in the meantime

[j-p-c]

Yes, Homebrew just updated LLVM to 15.0.1, and I can confirm that this is fixed.