UBSAN is sensitive to "compact returns"

[gvanem]

In lack of a better name than "compact returns", it seems clang with UBSAN is sensitive to a syntax like enum { a, b, c } func (args). Perfectly legal C-code. This little GNU-makefile with the flag -fsanitize=undefined shows the problem:

ubsan-crash.mak

``` # # A rewrite of libcurl's 'lib/content_encoding.c' for # the issue: # https://github.com/curl/curl/issues/12618 # CC = clang-cl CFLAGS = -nologo -fsanitize=undefined default: crash crash: ubsan_crash.c FORCE $(CC) -c $(CFLAGS) $< no_crash: ubsan_no_crash.c FORCE $(CC) -c $(CFLAGS) $< ubsan_crash.c: $(MAKEFILELISTS) $(info Generating $@) $(file > $@, $(ubsan_crash_c)) ubsan_no_crash.c: $(MAKEFILELISTS) $(info Generating $@) $(file > $@, $(ubsan_no_crash_c)) FORCE: ; clean: rm -f ubsan_crash.c ubsan_crash.obj \ ubsan_no_crash.c ubsan_no_crash.obj # # This is similar to this "crash-point" # https://github.com/curl/curl/blob/master/lib/content_encoding.c#L372 # # where it seems clang + UBSAN is sensitive to a syntax like # "enum { a, b, c } func (args)" # define ubsan_crash_c enum { GZIP_OK, GZIP_BAD, GZIP_UNDERFLOW } check_gzip_header (unsigned char const *data, size_t len, size_t *headerlen) { (void) data; (void) len; (void) headerlen; return (GZIP_OK); } endef # # A rewrite into a typedef'ed 'gzip_status' works fine. # define ubsan_no_crash_c typedef enum { GZIP_OK, GZIP_BAD, GZIP_UNDERFLOW } gzip_status; gzip_status check_gzip_header (unsigned char const *data, size_t len, size_t *headerlen) { (void) data; (void) len; (void) headerlen; return (GZIP_OK); } endef ```

Running make -f ubsan-crash.mak, gives me:

Generating ubsan_crash.c
clang-cl -c -nologo -fsanitize=undefined ubsan_crash.c
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associa
ted run script.
Stack dump:
0.      Program arguments: clang-cl -c -nologo -fsanitize=undefined ubsan_crash.c
1.      <eof> parser at end of file
2.      ubsan_crash.c:5:5: LLVM IR generation of declaration 'check_gzip_header'
3.      ubsan_crash.c:5:5: Generating code for declaration 'check_gzip_header'
Exception Code: 0xC0000005
 #0 0x00007ff6df60dfc7 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x155dfc7)
 #1 0x00007ff6e0bcf961 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x2b1f961)
 #2 0x00007ff6e0bdad39 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x2b2ad39)
 #3 0x00007ff6e0bd42a4 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x2b242a4)
 #4 0x00007ff6e0bd50d9 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x2b250d9)
 #5 0x00007ff6e0bd4082 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x2b24082)
 #6 0x00007ff6e0bcaf9d (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x2b1af9d)
 #7 0x00007ff6e0725d15 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x2675d15)
 #8 0x00007ff6e072984c (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x267984c)
 #9 0x00007ff6e072c98f (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x267c98f)
#10 0x00007ff6df5171eb (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x14671eb)
#11 0x00007ff6df50fe83 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x145fe83)
#12 0x00007ff6df51447b (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x146447b)
#13 0x00007ff6df50ef0d (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x145ef0d)
#14 0x00007ff6e12a31dc (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x31f31dc)
#15 0x00007ff6df946c99 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x1896c99)
#16 0x00007ff6e11fcf69 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x314cf69)
#17 0x00007ff6df8b12e2 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x18012e2)
#18 0x00007ff6de66d26d (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x5bd26d)
#19 0x00007ff6de6ffb7e (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x64fb7e)
#20 0x00007ff6de0b8bd6 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x8bd6)
#21 0x00007ff6de0b53a9 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x53a9)
#22 0x00007ff6df73dffd (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x168dffd)
#23 0x00007ff6de5b1845 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x501845)
#24 0x00007ff6df73d7ce (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x168d7ce)
#25 0x00007ff6de658085 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x5a8085)
#26 0x00007ff6de6583ce (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x5a83ce)
#27 0x00007ff6de63e40b (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x58e40b)
#28 0x00007ff6de0b4c2a (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x4c2a)
#29 0x00007ff6de0c6f14 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x16f14)
#30 0x00007ff6e264f130 (f:\ProgramFiler\LLVM-17.0\win64\bin\clang-cl.exe+0x459f130)
#31 0x00007ff9bca77344 (C:\Windows\System32\KERNEL32.DLL+0x17344)
#32 0x00007ff9bcc226b1 (C:\Windows\SYSTEM32\ntdll.dll+0x526b1)
clang-cl: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 17.0.1
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: f:\ProgramFiler\LLVM-17.0\win64\bin
clang-cl: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-cl: note: diagnostic msg: c:\temp\ubsan_crash-e86b08.c
clang-cl: note: diagnostic msg: c:\temp\ubsan_crash-e86b08.sh
clang-cl: note: diagnostic msg:

And running make -f ubsan-crash.mak no_crash is OK.

Version-info: clang-cl --version:

clang version 17.0.1
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: F:\ProgramFiler\LLVM-17.0\win64\bin

On Win-10, version 22H2 (OS-build 19045.3803).

[gvanem]

And adding -fno-sanitize=function to the above CFLAGS is off-course also OK; no crash.

[dsseng]

Didn't manage to reproduce neither on local machine nor Godbolt. Maybe a Windows-specific issue somehow?

[gvanem]

Maybe a Windows-specific issue somehow?

Perhaps. You (or someone else), should try it on Windows then?