Issue |
77074
|
Summary |
UBSAN is sensitive to "compact returns"
|
Labels |
new issue
|
Assignees |
|
Reporter |
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 a little GNU-makefile with the flag `-fsanitize=undefined` that shows the problem:
<details>
<summary>ubsan-crash.mak</summary>
```
#
# 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
```
</details>
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).
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs