Asan leaks in Vulkan

[GMNGeoffrey]

We have leaks detected by asan (well lsan really) in our vulkan tests. For now I'm disabling vulkan from the asan bot I'm bringing up. I'm not sure if this is something we can fix, at least for swiftshader, or whether we just need to figure out the right sanitizer suppressions.

Logs: https://gist.github.com/13f0f1d8bf176ec8c0d04145fc92e021

[ScottTodd]

I found a few issues here, but haven't yet figured out the right solutions.

---

IREE_ASSERT_OK leaks iree_status_t structures for non-ok statuses

71: ==108401==ERROR: LeakSanitizer: detected memory leaks
71: 
71: Direct leak of 64 byte(s) in 1 object(s) allocated from:
71:     #0 0x4a45e7 in __interceptor_posix_memalign (/usr/local/google/home/scotttodd/code/iree-build/iree/hal/vulkan/dynamic_symbols_test+0x4a45e7)
71:     #1 0x4e63f6 in iree_aligned_alloc /usr/local/google/home/scotttodd/code/iree/iree/base/allocator.h:135:10
71:     #2 0x4e612d in iree_status_allocate /usr/local/google/home/scotttodd/code/iree/iree/base/status.c:395:60
71:     #3 0x4e04fd in iree::hal::vulkan::DynamicSymbols::CreateFromSystemLoader(iree::ref_ptr<iree::hal::vulkan::DynamicSymbols>*) /usr/local/google/home/scotttodd/code/iree/iree/hal/vulkan/dynamic_symbols.cc:168:12

The code for that lives in https://github.com/google/iree/blob/main/iree/testing/status_matchers.h and was mostly written back before the C++ -> C HAL rewrite. Removing the C++ iree::Status class and updating the test macros to be leak free and built on top of the C API seems like good cleanup.

https://github.com/google/iree/blob/6258b50051e4aeb97ebc10f28e9e240760366c6f/iree/hal/vulkan/dynamic_symbols_test.cc#L43-L45

---

dynamic library loading (dlopen/dlsym/dlclose) interferes with ASAN reporting and symbolization

We open libvulkan.so, but ASAN has trouble understanding that and constructing a useful leak report. It seems like ASAN needs loaded libraries to remain open at process exit: see https://stackoverflow.com/questions/44627258/addresssanitizer-and-loading-of-dynamic-libraries-at-runtime-unknown-module and various issues on GitHub. Without any changes, I see all these <unknown module> addresses in the ASAN report:

71: ==110995==ERROR: LeakSanitizer: detected memory leaks
71: 
71: Direct leak of 72704 byte(s) in 1 object(s) allocated from:
71:     #0 0x4a3b7d in malloc (/usr/local/google/home/scotttodd/code/iree-build/iree/hal/vulkan/dynamic_symbols_test+0x4a3b7d)
71:     #1 0x7f8aadec3cd5  (<unknown module>)
71:     #2 0x7f8aadeb31e2  (<unknown module>)
71: 
71: Direct leak of 6304 byte(s) in 4 object(s) allocated from:
71:     #0 0x4a3d12 in __interceptor_calloc (/usr/local/google/home/scotttodd/code/iree-build/iree/hal/vulkan/dynamic_symbols_test+0x4a3d12)
71:     #1 0x7f8ab813c2db  (<unknown module>)
71: 
71: Direct leak of 896 byte(s) in 1 object(s) allocated from:
71:     #0 0x4a3e73 in __interceptor_realloc (/usr/local/google/home/scotttodd/code/iree-build/iree/hal/vulkan/dynamic_symbols_test+0x4a3e73)
71:     #1 0x7f8ab813b582  (<unknown module>)
71: 
71: Direct leak of 192 byte(s) in 2 object(s) allocated from:
71:     #0 0x4a3b7d in malloc (/usr/local/google/home/scotttodd/code/iree-build/iree/hal/vulkan/dynamic_symbols_test+0x4a3b7d)
71:     #1 0x7f8aae67bc97  (<unknown module>)
71: 
71: Indirect leak of 139616 byte(s) in 437 object(s) allocated from:
71:     #0 0x4a3d12 in __interceptor_calloc (/usr/local/google/home/scotttodd/code/iree-build/iree/hal/vulkan/dynamic_symbols_test+0x4a3d12)
71:     #1 0x7f8ab813c2db  (<unknown module>)
71: 
71: Indirect leak of 4923 byte(s) in 7 object(s) allocated from:
71:     #0 0x4a3b7d in malloc (/usr/local/google/home/scotttodd/code/iree-build/iree/hal/vulkan/dynamic_symbols_test+0x4a3b7d)
71:     #1 0x7f8aae67bc97  (<unknown module>)
71: 
71: Indirect leak of 4871 byte(s) in 361 object(s) allocated from:
71:     #0 0x4a3b7d in malloc (/usr/local/google/home/scotttodd/code/iree-build/iree/hal/vulkan/dynamic_symbols_test+0x4a3b7d)
71:     #1 0x7f8ab813be74  (<unknown module>)
71: 
71: Indirect leak of 752 byte(s) in 6 object(s) allocated from:
71:     #0 0x4a3e73 in __interceptor_realloc (/usr/local/google/home/scotttodd/code/iree-build/iree/hal/vulkan/dynamic_symbols_test+0x4a3e73)
71:     #1 0x7f8ab813b582  (<unknown module>)
71: 
71: SUMMARY: AddressSanitizer: 230258 byte(s) leaked in 819 allocation(s).

I tried some variations on our dlopen() flags (mainly adding RTLD_NODELETE) and removing our call to dlclose(), but I still can't get useful data from ASAN.
https://github.com/google/iree/blob/6258b50051e4aeb97ebc10f28e9e240760366c6f/iree/base/internal/dynamic_library_posix.c#L176-L179
https://github.com/google/iree/blob/6258b50051e4aeb97ebc10f28e9e240760366c6f/iree/base/internal/dynamic_library_posix.c#L234-L250

[benvanik]

So long as IREE_ASSERT_OK is tied to gtest it's fine to wrap in an iree::Status - if we wanted to switch to a C unit testing framework then we'd want to make it safe.

We could try making the macros something like:

#define IREE_ASSERT_OK(rexpr) ASSERT_THAT(iree::Status(rexpr), ..)

or

#define IREE_ASSERT_OK(rexpr) \
  { \
    iree::Status __status = {(rexpr)}; \
    ASSERT_THAT(__status...) \
  }

though we may want to do some && trickery to ensure they aren't used later; this would be bad:

iree_status_t status = ...;
IREE_ASSERT_OK(status);
do_something(status);  // status not valid here

All for making it harder to leak them in tests in the normal path --- leaks in failure cases are fine (as barely any test code is expected to gracefully fail).

[ScottTodd]

Yeah, the status leaks came up when I broke dlopen by passing the wrong flags - I finally saw accurate asan stacks, but for status code and not Vulkan code :P

Any dlopen()/dlclose() tweaks may need to reach into the Vulkan loader as well: https://github.com/KhronosGroup/Vulkan-Loader/blob/8198bebc7fe31c3da54b1dfacbb92e8697646701/loader/vk_loader_platform.h#L238-L257. I'm also trying some LD_PRELOAD tricks but no luck so far.

[ScottTodd]

Editing the Vulkan Loader code linked above helped me get useful reports from ASAN, which all pointed to leaks throughout libnvidia-glcore.so on my machine. When I switch to using SwiftShader, I see no leaks in IREE's Vulkan tests.

Possible next steps:

• Debug inside our Docker images, with dlopen/dlclose changes to IREE's code and the Vulkan Loader
• Update our SwiftShader build to a more recent commit - maybe there were leaks that were fixed
• Investigate ASAN suppressions (these might also need the dlopen/dlclose changes?)

[ScottTodd]

Updating SwiftShader helped!

Most Vulkan tests are fixed + enabled under ASan now.
These remain:
https://github.com/google/iree/blob/bcb6199e19d5a6320397258a8028fc5ec3459d0d/build_tools/kokoro/gcp_ubuntu/cmake/linux/x86-swiftshader-asan/build.sh#L105-L111

with logs like

Tracer caught signal 11: addr=0x0 pc=0x50c558 sp=0x7fb28fdffd10
==50923==LeakSanitizer has encountered a fatal error.
==50923==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==50923==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)

(full logs here)

Next step is to try that debugging hint (LSAN_OPTIONS), possibly with dlclose() disabled in IREE code and in libvulkan.so.1 (the Vulkan Loader). I wasn't able to repro those crashes on my local machine, so we might need to debug under Docker.

[ScottTodd]

Still seeing a few ASan+Vulkan tests fail occasionally with that LeakSanitizer crash

e2e/models/mnist_fake_weights.mlir: https://github.com/iree-org/iree/runs/7768946982?check_suite_focus=true
e2e/models/fragment_000.mlir.test: #10004

Seems like the failures are flakes, since they keep popping up one at a time?