hctim added a comment.
In D127812#4012276 <https://reviews.llvm.org/D127812#4012276>, @ilinpv wrote:
> I've managed to reproduce "MemorySanitizer: use-of-uninitialized-value" error
> locally, thank you @hctim for help!
> If I understand it right, it seems **MSan didn't handle correctly
> SmallVector** - a variable-sized array with some number of elements in-place
> and heap allocation for additional elements if needed:
>
> clang/lib/Sema/SemaDeclAttr.cpp:3615 SmallVector<SmallString<64>, 2>
> StringsBuffer;
>
> There were 2 elements in-placed for StringsBuffer and tests which require 3
> failed with MSan use-of-uninitialized-value error.
> With number of StringsBuffer in-placed elements set to 3
>
> SmallVector<SmallString<64>, 3> StringsBuffer;
>
> all use-of-uninitialized-value errors have gone.
I'm not sure "MSan didn't handle correctly SmallVector" is the case. Given your
diagnosis of 3-elements-vs-2, I'm guessing the root cause is that
`clang/lib/Sema/SemaDecl.cpp:11369` is wrong:
!std::equal(CurClones->featuresStrs_begin(),
CurClones->featuresStrs_end(),
NewClones->featuresStrs_begin()))) {
This construction of `std::equal` is very error-prone, as if `NewClones.size()
< CurClones.size()`, then this invariable leads to buffer-overflow. I'm
wondering if that's the underlying cause, it would seem entirely possible that
expanding the in-place elements are always "initialized" from MSan's
perspective and so the current code has a false-negative, and your new code
made it so that the vector is now heap-based, which is revealing the underlying
issue. Maybe worth trying one more thing and adding an
`assert(CurClones->size() <= NewClones->size());` to double check?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D127812/new/
https://reviews.llvm.org/D127812
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
