blacklist does not seem to work for interceptor functions

[GoogleCodeExporter]

What steps will reproduce the problem?
1.
--- foo.cxx -----
#include <stdlib.h>
#include <string.h>

int bad_foo() {
  char* s = new char[10];
  int i = strlen(s);
  return i;
}

int main() { return bad_foo(); }
2.
 cat bl.txt
fun:bad_foo
fun:*strlen*
3.
clang++ -fsanitize=memory -fsanitize-blacklist=bl.txt -fPIE -pie 
-fno-omit-frame-pointer -g -O2 foo.cxx
./a.out
UMR in __interceptor_strlen at offset 0 inside [0x60200000f7f0, +1) 
==10520== WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f57737abb66 in bad_foo() /home/hoffman/foo.cxx:6
    #1 0x7f57737abb66 in main /home/hoffman/foo.cxx:18
    #2 0x7f5772324ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #3 0x7f57737ab9cc in _start (/home/hoffman/a.out+0x739cc)

SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/hoffman/foo.cxx:6 
bad_foo()

What is the expected output? What do you see instead?
I would expect there to be some way to black list this call.  bad_foo does not 
work and strlen does not work either.

What version of the product are you using? On what operating system?
linux ubuntu clang3.4

Original issue reported on code.google.com by bill.hof...@kitware.com on 9 Oct 2014 at 12:48

[GoogleCodeExporter]

Yes, that's a current limitation.
For this we would need to set some kind of thread-local flag when entering a 
blacklisted function and clear it when leaving it, and around nested calls.

Original comment by euge...@google.com on 9 Oct 2014 at 8:41

• Changed state: Accepted

[GoogleCodeExporter]

Are there any workarounds?  Basically, gtest has this issue with strlen, making 
it so that we can not really use msan unless we can figure out a way to 
suppress this.

Original comment by bill.hof...@kitware.com on 9 Oct 2014 at 1:50

[GoogleCodeExporter]

Not without changing the code, I'm afraid.
What's the issue? We are using gtest quite heavily with msan and have not seen 
any.

Original comment by euge...@google.com on 9 Oct 2014 at 1:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

(apologies for the double post)

Below is the stack trace from a defect detected by msan from gtest.  This was 
obtained by compiling sample1.cc (from the gtest sample dir) with the 
appropriate msan flags and then running it.  We're using gtest 1.7.0 in this 
example.

$ ./sample1 
Running main() from gtest_main.cc
UMR in __interceptor_strcmp at offset 0 inside [0x60400000efd8, +2) 
==5724== WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7fb4c83bd936 in testing::internal::String::CStringEquals(char const*, char const*) (/projects/gtest_samples/bin/sample1+0xae936)
    #1 0x7fb4c83c5313 in testing::internal::PrettyUnitTestResultPrinter::OnTestIterationStart(testing::UnitTest const&, int) (/projects/gtest_samples/bin/sample1+0xb6313)
    #2 0x7fb4c83c7783 in testing::internal::TestEventRepeater::OnTestIterationStart(testing::UnitTest const&, int) (/projects/gtest_samples/bin/sample1+0xb8783)
    #3 0x7fb4c83ccaf3 in testing::internal::UnitTestImpl::RunAllTests() (/projects/gtest_samples/bin/sample1+0xbdaf3)
    #4 0x7fb4c83ea8e2 in bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) (/projects/gtest_samples/bin/sample1+0xdb8e2)
    #5 0x7fb4c83e02b0 in bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) (/projects/gtest_samples/bin/sample1+0xd12b0)
    #6 0x7fb4c83cc83a in testing::UnitTest::Run() (/projects/gtest_samples/bin/sample1+0xbd83a)
    #7 0x7fb4c83b9da0 in RUN_ALL_TESTS() (/projects/gtest_samples/bin/sample1+0xaada0)
    #8 0x7fb4c83b9d7b in main (/projects/gtest_samples/bin/sample1+0xaad7b)
    #9 0x7fb4c6f0d76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226
    #10 0x7fb4c83b9b0c in _start (/projects/gtest_samples/bin/sample1+0xaab0c)

SUMMARY: MemorySanitizer: use-of-uninitialized-value ??:0 
testing::internal::String::CStringEquals(char const*, char const*)
Exiting

Original comment by zack.gal...@kitware.com on 9 Oct 2014 at 4:42

[GoogleCodeExporter]

Can you run this with msan's track-origins? (add 
-fsanitize-memory-track-origins=2)

Original comment by konstant...@gmail.com on 9 Oct 2014 at 6:46

[GoogleCodeExporter]

We're running clang-3.4, so I couldn't pass in the =2 option.  But here's the 
new information:

  Uninitialized value was created by a heap allocation
    #0 0x7fcca37933b3 in operator new(unsigned long) (/projects/gtest_samples/bin/sample1+0x9e3b3)
    #1 0x7fcca29613c8 (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xba3c8)
    #2 0x7fcca2962f17 (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xbbf17)

Original comment by zack.gal...@kitware.com on 9 Oct 2014 at 7:00

[GoogleCodeExporter]

1. don't use msan from 3.4, use the fresh one. 
2. msan requires that all the libraries are msan-instrumented, including 
libstdc++/libc++. In most cases we use instrumented libc++ -- it is simpler to 
build. 

eugenis@ or samsonov@, do we have a page describing how to use instrumented 
libc++ with msan? 

Original comment by konstant...@gmail.com on 9 Oct 2014 at 8:50

[GoogleCodeExporter]

We've got a bot that does it...
Sure, we need a page, too.

Original comment by euge...@google.com on 10 Oct 2014 at 8:41

[GoogleCodeExporter]

Adding Project:MemorySanitizer as part of GitHub migration.

Original comment by gli...@google.com on 30 Jul 2015 at 9:22

• Added labels: ProjectMemorySanitizer