ci: run sanitizers

[dunglas]

Replaces #806.

[dunglas]

ASAN is now triggered, but I'm not sure if it is configured properly or useful:

• reports look like false positives
• I introduced a leak on purpose and it isn't detected

EDIT: it only works for the linker, there is a problem with libphp.so that I'm trying to debug.

[dunglas]

The tests are green, but the leak I added on purpose is undetected 😢

[TimWolla]

@dunglas Did you try with an obvious buffer overflow to see if ASAN is functional:

$ cat test.c
#include <stdlib.h>

int
main(void) {
	char *foo = malloc(5);
	foo[20] = 'x';
}
$ clang -fsanitize=address test.c
$ ./a.out
=================================================================
==176148==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000024 at pc 0x5c4dab147803 bp 0x7fffe3cfb400 sp 0x7fffe3cfb3f8
WRITE of size 1 at 0x602000000024 thread T0
    #0 0x5c4dab147802 in main (/tmp/a.out+0xf4802) (BuildId: 13a8f7535c789ccc0a6259a3e27a5befb40c7173)
    #1 0x78cb93c2814f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
    #2 0x78cb93c28208 in __libc_start_main csu/../csu/libc-start.c:360:3
    #3 0x5c4dab0712e4 in _start (/tmp/a.out+0x1e2e4) (BuildId: 13a8f7535c789ccc0a6259a3e27a5befb40c7173)

0x602000000024 is located 15 bytes after 5-byte region [0x602000000010,0x602000000015)
allocated by thread T0 here:
    #0 0x5c4dab10bf32 in __interceptor_malloc (/tmp/a.out+0xb8f32) (BuildId: 13a8f7535c789ccc0a6259a3e27a5befb40c7173)
    #1 0x5c4dab1477c1 in main (/tmp/a.out+0xf47c1) (BuildId: 13a8f7535c789ccc0a6259a3e27a5befb40c7173)
    #2 0x78cb93c2814f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16

SUMMARY: AddressSanitizer: heap-buffer-overflow (/tmp/a.out+0xf4802) (BuildId: 13a8f7535c789ccc0a6259a3e27a5befb40c7173) in main
Shadow bytes around the buggy address:
  0x601ffffffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x601ffffffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x601ffffffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x601fffffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x601fffffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x602000000000: fa fa 05 fa[fa]fa fa fa fa fa fa fa fa fa fa fa
  0x602000000080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000000100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000000180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000000200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000000280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==176148==ABORTING

?

[dunglas]

@TimWolla interesting, I added your snippet: the error is caught on standard builds... but not on ASAN builds!

[iluuu1994]

Where are you actually building frankenphp? Is this part of go test?

[dunglas]

@iluuu1994 Yes

[iluuu1994]

Can you dump the compiler output somehow? Are you sure the flags are actually passed properly?

[dunglas]

I printed as many details as possible (and caught a typo in LDFLAGS that can explain many issues in my earlier attempts ^^), but sanitizers still don't report the issue.

[iluuu1994]

TERM='dumb' clang -I . -fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=$WORK/b093=/tmp/go-build -gno-record-gcc-switches -fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I $WORK/b093/ -fsanitize=address -g -O0 -fsanitize=address -DZEND_TRACK_ARENA_ALLOC -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib -Wall -Werror -fstack-protector-strong -fpic -fpie -O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib -D_GNU_SOURCE -frandom-seed=yLoYn2_58KZYoFX-HPTV -o $WORK/b093/_x006.o -c frankenphp.c

You have both an -O2 and -O0, it's possible that the problematic code is optimized away.

[dunglas]

Good catch @iluuu1994, that was the problem and the sanitizer now works! Thank you very much.

I'll have to refactor our build process as it doesn't look possible to override the options defined directly in the cgo directives using the environment variables, but that shouldn't be too hard.

[iluuu1994]

No worries. Note that you may run into issues with msan. msan requires instrumenting all code, it is not enough to instrument some code. In other words, all static and dynamic libraries must be recompiled with msan enabled. Our msan job builds limited extensions for exactly this reason, e.g. no openssl.