Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Msan instrumented lrte #15

Closed
dionescu opened this issue Mar 27, 2016 · 8 comments
Closed

Msan instrumented lrte #15

dionescu opened this issue Mar 27, 2016 · 8 comments

Comments

@dionescu
Copy link

Not an issue, but a feature request.

Given the recent changes that moved asan/msan/tsan to using LRTE, I think it would be really nice if the LRTE release would provide msan instrumented libc++ / libstdc++.

@mzhaom
Copy link
Member

mzhaom commented Apr 4, 2016

I might miss something, but isn't msan instrumented libstdc++ part of clang build coming with LRTE(or any prebuilt clang compiler)?

@dionescu
Copy link
Author

Maybe https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo confused me. I tried their gtest example and it's failing but i think that may be a gtest msan bug.

@dionescu
Copy link
Author

Upon further investigation, I still think LRTE is not using an MSAN instrumented libstdc++. For instance, one gets the MSAN error below when running bazel run --config=msan -- :bank-client. According to protocolbuffers/protobuf#1099, this error is not an MSAN bug in protobuf but is rather due to a non-instrumented libstdc++

INFO: Running command line: bazel-bin/examples/rpc/bank-client --alsologtostderr
==2977==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7fc7ed45f510 in google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void const*, int> >::ValidateSymbolName(std::string const&) /home/dragos/.cache/bazel/_bazel_dragos/995c3226c255d07b9777857aa6c179dd/trunk-ro/external/protobuf/src/google/protobuf/descriptor_database.cc:238:24
#1 0x7fc7ed45d11f in google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void const*, int> >::AddSymbol(std::string const&, std::pair<void const*, int>) /home/dragos/.cache/bazel/_bazel_dragos/995c3226c255d07b9777857aa6c179dd/trunk-ro/external/protobuf/src/google/protobuf/descriptor_database.cc:93:8
#2 0x7fc7ed451c22 in google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void const*, int> >::AddFile(google::protobuf::FileDescriptorProto const&, std::pair<void const*, int>) /home/dragos/.cache/bazel/bazel_dragos/995c3226c255d07b9777857aa6c179dd/trunk-ro/external/protobuf/src/google/protobuf/descriptor_database.cc:68:10
#3 0x7fc7ed44e32b in google::protobuf::EncodedDescriptorDatabase::Add(void const
, int) /home/dragos/.cache/bazel/bazel_dragos/995c3226c255d07b9777857aa6c179dd/trunk-ro/external/protobuf/src/google/protobuf/descriptor_database.cc:312:12
#4 0x7fc7ed353c0d in google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const
, int) /home/dragos/.cache/bazel/_bazel_dragos/995c3226c255d07b9777857aa6c179dd/trunk-ro/external/protobuf/src/google/protobuf/descriptor.cc:1157:3
#5 0x7fc7ed32dd52 in examples::protobuf_AddDesc_examples_2frpc_2fbank_2eproto() /home/dragos/.cache/bazel/_bazel_dragos/995c3226c255d07b9777857aa6c179dd/trunk-ro/bazel-out/crosstool_v2_clang-fastbuild/genfiles/examples/rpc/bank.pb.cc:105:3
#6 0x7fc7eda0a07c in __libc_csu_init /usr/lrte/v2/debug-src/src/glibc-2.21/csu/elf-init.c:88
#7 0x7fc7ebe2689e in __libc_start_main (/usr/lrte/v2/lib64/libc.so.6+0x2089e)
#8 0x7fc7ed2bd0c8 in _start /usr/lrte/v2/debug-src/src/glibc-2.21/csu/../sysdeps/x86_64/start.S:108

SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/dragos/.cache/bazel/_bazel_dragos/995c3226c255d07b9777857aa6c179dd/trunk-ro/external/protobuf/src/google/protobuf/descriptor_database.cc:238:24 in google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void const*, int> >::ValidateSymbolName(std::string const&)

@dionescu
Copy link
Author

Or maybe LRTE has the instrumented version but the :msan config does not tell Bazel to use it.

@dionescu
Copy link
Author

Noticed some more odd behaviour when building with LRTE. I would expect it to use libstdc++ from under /usr/lrte but ldd says differently. Am I missing something?

bazel build --crosstool_top //tools/lrte:toolchain :hello

ldd ../bazel-bin/examples/hello
../bazel-bin/examples/hello: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ../bazel-bin/examples/hello)
linux-vdso.so.1 => (0x00007ffdbca93000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3e5f383000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3e5f16d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3e5ef4f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3e5eb8a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3e5e884000)
/usr/lrte/v2/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f3e5f687000)

@dionescu
Copy link
Author

Ah, I should have used the ldd from LRTE.

@dionescu
Copy link
Author

I think this can be closed. The clang that comes with LRTE does not have a MSAN instrumented libstdc++ as far as I can tell. I have a script to create the instrumented version in my fork of LRTE: https://github.com/dionescu/lrte

@mzhaom
Copy link
Member

mzhaom commented Jan 22, 2017

Thanks for the update. Really appreciate your investigation and script.

@mzhaom mzhaom closed this as completed Jan 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants