search for: msan_options

I recently broke a sanitizer buildbot but I am unable to reproduce the failure. The buildbot that failed is http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/2959 I looked around in the logs, looking for the config/build commands that would reproduce the failure. The problem is that the bot seems to be using a script which I don't have access to

...d2_asan, so I'll have to kick it a bit first. I think the bot usually gives a readable error report, but it doesn't work > for this test because the test is passing stderr to FileCheck. Lots of > tests do that, and we should find a way to make that work. We might want > to pass MSAN_OPTIONS=log_path=/tmp/something.log and then cat that file > from lit if it's non-empty. > Yeah. From the output, I can see part of the msan failure, but I can't see the whole thing. Worse, I can't even replicate it. Diego. -------------- next part -------------- An HTML attachment was...

...d_msan_clang/../examples/c/test_capi.c:2794:5 #4 0x7fa7d78f960f in __libc_start_main (/usr/lib/libc.so.6+0x2060f) SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/dsl11/dev/klee/z3/z3_upstream/build_msan_clang/../src/api/api_log.cpp:33:13 in Z3_open_log Exiting ``` Side note using ``MSAN_OPTIONS="halt_on_error=0`` doesn't seem to do anything, the application always exits when it hits the reported bug. I'd like a way to catch this in gdb but I'm not sure how to do it. I took a look. MSan is complaining about this code ``` std::ostream * g_z3_log = 0; ... Z3_bool Z3_...

Hi, # TL;DR I've been building an application with and without the address sanitizer (with gcc 5.3 and clang 3.7.1) and I've observed that the application's behaviour changes (assertion hit/ not hit). I'm wondering if this could be a bug in address sanitizer or if the application I'm running is just buggy (e.g. doing bad things like relying on memory layout, etc.). I'm