UBSAN may produce unusable traces

[lzaoral]

Even though csutils/csdiff#130 improves the situation, UBSAN does not guarantee that the path in the first entry of the backtrace will be absolute. E.g. the following report from coreutils will be silenced:

Error: UBSAN_WARNING:
  2 ../src/join.c:1375:45: runtime error: load of address 0x558317b96301 with insufficient space for an object of type 'char'
  3 0x558317b96301: note: pointer points here
  4 # 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  41 00 00 00 00
  5 #              ^-
  6 ../src/join.c:1375: note: single_binary_main_join() at 0x5583160e3481
  7 ../src/coreutils.c:128: note: launch_program() at 0x55831602d9ee
  8 ../src/coreutils.c:178: note: main() at 0x55831602a906
  9 /lib64/libc.so.6: note: __libc_start_call_main() at 0x7f5197649b49
 10 /lib64/libc.so.6: note: __libc_start_main_alias_2() at 0x7f5197649c0a
 11 coreutils-9.3/single/src/coreutils: note: _start() at 0x55831602ad34

We can use csexec to track the working directory and UBSAN logs from the given process and fix them afterwards. The log files end with the PID of the sanitized process, so it should be quite easy to track it because each child will have its own csexec execution.

[kdudka]

Are the paths relative to the working directory at run time or build time? If the latter, csexec is not going to help us.

[lzaoral]

This seems like a bug in GCC. Because GCC and Clang behave differently in this case:

$ clang -fsanitize=undefined -g -O0 ../symb/test.c
$ UBSAN_OPTIONS=print_stacktrace=1 ./a.out
../symb/test.c:5:12: runtime error: index 4 out of bounds for type 'int[4]'
    #0 0x42b35c in main /home/lukas/tmp/bin/../symb/test.c:5:12
    #1 0x7f7c4021cb49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
    #2 0x7f7c4021cc0a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
    #3 0x4033a4 in _start (/home/lukas/tmp/bin/a.out+0x4033a4) (BuildId: 52afc251f68713a934cde4df480a3d091e9fc3f4)

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../symb/test.c:5:12 in

$ cc -fsanitize=undefined -g ../symb/test.c
$ UBSAN_OPTIONS=print_stacktrace=1 ./a.out
../symb/test.c:5:13: runtime error: index 4 out of bounds for type 'int [4]'
    #0 0x40114c in main ../symb/test.c:5
    #1 0x7fab70c49b49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
    #2 0x7fab70c49c0a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
    #3 0x401074 in _start (/home/lukas/tmp/bin/a.out+0x401074) (BuildId: d38972f553a09517259535880b4025e8ef8a6f79)

../symb/test.c:5:13: runtime error: load of address 0x7ffe0400e5b0 with insufficient space for an object of type 'int'
0x7ffe0400e5b0: note: pointer points here
 fe 7f 00 00  50 e6 00 04 fe 7f 00 00  4a 9b c4 70 ab 7f 00 00  e8 82 df 70 ab 7f 00 00  d8 e6 00 04
              ^
    #0 0x401161 in main ../symb/test.c:5
    #1 0x7fab70c49b49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
    #2 0x7fab70c49c0a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
    #3 0x401074 in _start (/home/lukas/tmp/bin/a.out+0x401074) (BuildId: d38972f553a09517259535880b4025e8ef8a6f79)

[lzaoral]

Idea for an temporary solution: Allow all UBSAN reports unconditionally. While the traces might be incomplete, such warning still informs us that some built and executed program contained an error with very high probability.

[kdudka]

If I understand it correctly, the problem is that csmock is dropping all findings where the path does not start with /builddir/build/BUILD/. We should somehow tweak it to allow relative paths, too. But it should not allow absolute paths such as /usr/include, /tmp/, etc.