Valgrind reports use of uninitialized value in any_range
Hi, I am using an any_range of std::unique_ptr values in one of my programs. When I analyse this with valgrind, it reports many uninitialized value usages in any_range, and I cannot explain this from my code. I managed to produce a small example to reproduce this. I would like to know if that is a real issue, or if can just create a valgrind suppression rule. #include <iostream> #include <boost/range.hpp> #include <boost/range/any_range.hpp> #include <boost/range/adaptors.hpp> struct Int { Int(int i): x(i) {} int x; }; int main( int argc, char* argv[] ) { typedef boost::any_range<Int*, boost::forward_traversal_tag, Int*, std::ptrdiff_t> R; std::vector<std::unique_ptr<Int>> v; v.push_back( std::make_unique<Int>(42) ); auto f = [](std::unique_ptr<Int> const& p) {return p.get();}; R r = v | boost::adaptors::transformed(f); auto x = (*boost::begin(r))->x; std::cout << x << std::endl; return 0; } Running this, valgrind reports a "Use of uninitialized value of size 8": # g++ --version g++ (GCC) 5.2.0 # g++ -std=c++1y -o test test.cpp # valgrind --version valgrind-3.11.0 # valgrind --track-origins=yes ./test ==8119== Memcheck, a memory error detector ==8119== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==8119== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==8119== Command: ./test ==8119== ==8119== Use of uninitialised value of size 8 ==8119== at 0x4010B8: main (in /tmp/test) ==8119== Uninitialised value was created by a stack allocation ==8119== at 0x40315D: boost::range_detail::any_iterator<Int*, boost::iterators::forward_traversal_tag, Int*, long, boost::any_iterator_buffer<64ul> >::dereference() const (in /tmp/test) ==8119== 42 ==8119== ==8119== HEAP SUMMARY: ==8119== in use at exit: 72,704 bytes in 1 blocks ==8119== total heap usage: 3 allocs, 2 frees, 72,716 bytes allocated ==8119== ==8119== LEAK SUMMARY: ==8119== definitely lost: 0 bytes in 0 blocks ==8119== indirectly lost: 0 bytes in 0 blocks ==8119== possibly lost: 0 bytes in 0 blocks ==8119== still reachable: 72,704 bytes in 1 blocks ==8119== suppressed: 0 bytes in 0 blocks ==8119== Rerun with --leak-check=full to see details of leaked memory ==8119== ==8119== For counts of detected and suppressed errors, rerun with: -v ==8119== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1) Best wishes, Jens PS: I've sent this to boost-users yesterday, but I now think that boost-devel is a better match. -- Dr. Jens Auer | CGI | Software Engineer CGI Deutschland Ltd. & Co. KG Rheinstraße 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer@cgi.com Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.
On 16 October 2015 at 07:45, Auer, Jens <jens.auer@cgi.com> wrote:
Hi,
I am using an any_range of std::unique_ptr values in one of my programs. When I analyse this with valgrind, it reports many uninitialized value usages in any_range, and I cannot explain this from my code. I managed to produce a small example to reproduce this. I would like to know if that is a real issue, or if can just create a valgrind suppression rule.
It's safe to ignore under all compilers and platforms, under all use-cases, that I have tried. Please see the Boost test matrix to confirm correct functioning. It is due to a sub-optimal implementation that I did for the underlying iterator small buffer optimisation. The any_iterator_buffer uses a boost::array<char,N> as a target for a placement new. I hope that by updating this code to use aligned_storage that the warning will go away. Since the start of the array is merely used (in the any_iterator implementation) as an argument to placement new I believe the alignment issues are irrelevant unless the type of the value_type is almost 64 bytes and the alignment of the value_type is greater than the alignment of the array. In practice, on the vast majority of platforms / compilers, this doesn't present a real problem. I'm sorry for the confusion my mistake has caused. I need to address this soon.
Best wishes, Jens
PS: I've sent this to boost-users yesterday, but I now think that boost-devel is a better match.
Regards, Neil
participants (2)
-
Auer, Jens
-
Neil Groves