- Boost - lists.preview.boost.org

Valgrind reports use of uninitialized value in any_range
by Auer, Jens 16 Oct '15

16 Oct '15

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(a)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.

2 1

Beginner Request for Contributing to Boost Library
by Arafat Khan 16 Oct '15

16 Oct '15

Hi Respected Sir/ Mam, I am Arafat Dad Khan, an undergraduate student at Indian Institute of Technology, Kharagpur. I wish to contribute to the Boost Library (Specifically Graph and Data Structures). I have decent knowledge of Algorithms and Data Structures and have consistently taken part in algorithmic competitions on websites such as Codechef and Spoj(Sphere online Judge ) you can view my profile here http://www.spoj.com/SPOJ/users/adk/ I am very new to open source, And i just need someone to guide me so that i could focus on the right areas to contribute. I am very comfortable with C++ language and learning complicated algorithms is great fun to me. Can anyone please tell me the ways in which i could contribute? If this is not the right place to ask newbie questions please tell me where i could ask the my questions. Thanks Arafat Dad Khan Indian Institute of Technology Kharagpur

4 3

We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)
by Hartmut Kaiser 16 Oct '15

16 Oct '15

Sorry for cross-posting. > Vicente J. Botet Escriba wrote: > > I have a branch > (https://github.com/boostorg/thread/tree/feature/non_blocking_futures) > that don't blocks on any future, but this will break async. FWIW, the design decision to let those (and only those) futures block on destruction which are returned from async was one of the really bad decisions made for C++11, however that's just my opinion (others agree, but yet others disagree). This flaw essentially caused us to spend many committee hours on discussions how to mitigate the situation, with proposed solutions ranging from 'leave it be as is' to as extreme as 'deprecate it now'. There seems to be a growing consensus however to develop other constructs which eventually could replace async, such as executors, etc. I'm a proponent of following that path. More generally, I strongly believe that we have to come up with a _coherent story_ for all kinds of (higher-level) parallelism in C++: task-based parallelism, asynchronous, continuation style programming, fork-join parallelism of heterogeneous tasks, simple fork-join (iteration based) parallelism, etc. All of this has to go hand in hand with a (orthogonal) vectorization story. We also need to think about integrating GPUs. The goal has to be to make parallelism in C++ independent of any external solutions such as OpenMP, OpenACC, etc. Many of the building blocks for this are already being discussed: executors and executor_traits for customizing the 'how and where' of task execution, executor parameters for grain-size control, and execution policies as the higher level facility allowing to tie everything together (see for instance HPX [7]). We (as a committee) already allow for passing execution policies as the first argument to parallel algorithms (Parallelism TS, N4505 [2]). We already have some facilities for task-based, asynchronous, and continuation style parallelism in place (Concurrency TS, N4501 [3]). We have a paper proposing task_blocks for fork-join parallelism of heterogeneous tasks (N4411 [4]). We have two competing (but converging) efforts for defining an executor concept (N4406 [5], PR0008R0 [6]). We have a (strong) proposal for simplifying continuation based programming (await, PR0057R0 [8]). We have attempts on integrating executors with existing facilities (Boost, HPX). We miss work on parallel ranges. We miss work on integrating data structures with data placement policies in conjunction with executors. We miss work on extending all of this to many-core, distributed, and high-performance computing. Etc. We (as a community) really need a higher level, over-arching approach which ties all of the above together! My plan is to work on a corresponding concept paper by the time of the committee meeting end of February 2016. Our group has outlined our current understanding and a possible approach to this here [1]. I'd like for this to be understood as a seed for a wider discussion. Needless to say, I'd very much like to collaborate on this with anybody interested in joining the effort. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu [1] http://stellar.cct.lsu.edu/pubs/executors_espm2_2015.pdf [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4505.pdf [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4501.html [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4411.pdf [5] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf [6] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0008r0.pdf [7] http://stellar-group.github.io/hpx/docs/html/hpx/manual/parallel.html [8] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0057r0.pdf

5 10

[WG21 mailing] N4453 Resumable expressions
by Niall Douglas 15 Oct '15

15 Oct '15

I'm finding Chris' paper on resumable expressions instead of compiler magic created resumable functions awfully compelling: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4453.pdf I essentially proposed the same with my functionally composed constexpr basic_future design some months ago. Would anyone else like to comment on this library based instead of compiler based resumable execution? I'm not against some compiler support for resumable execution, but I am finding the await based proposal highly problematic, and Chris does an excellent job in summarising my own thoughts on what's wrong with it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 17

Policy for individual library versioning
by Louis Dionne 15 Oct '15

15 Oct '15

Hi, I wonder whether there is a policy for how to version individual Boost libraries. Should individual libraries follow their own versioning scheme, or should they stick to the Boost versioning scheme? For example, Hana is currently in v0.4 and following Semantic Versioning[1]. I am wondering whether I should change Hana's version to 1.60.0 when it will be released with Boost 1.60.0, and from then on follow that versioning scheme (and drop Semantic Versioning, which I'm OK with). Hence, I would bump to 1.61.0 when Boost 1.61.0 is released, and so on. The other option is to stick with my current versioning scheme and simply document the correspondence between Hana vA.B.C and Boost vX.Y.Z. Is there any agreed-upon way to handle this? Regards, Louis [1]: http://semver.org

3 4

1.60 closes for new libraries and breaking changes in a week
by Vladimir Prus 15 Oct '15

15 Oct '15

Folks, the deadline for new libraries and breaking changes for 1.60 is next Wednesday, Oct 21. Please get big changes in by that date. Thanks, Volodya

4 7

Re: [boost] [c++std-parallel-2020] Re: We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)
by Peter Dimov 14 Oct '15

14 Oct '15

Lawrence Crowl wrote: > First, std::async and std::future have no flaws for what they were > designed to do. They were designed to provide relatively easy parallelism > for small core systems under the fork-join model. I thought that it was well established by now that std::async isn't very useful for fork-join (if at all.) First, it's required to execute each (asynchronous) task as-if in a new thread with respect to thread locals, which in practice means "in a new thread". Second, it has to allocate the future shared state. These two non-flaws kill its performance for fork-join parallelism. The first one is not related to its use of std::future, but the second one is. Given an interface of the form X x; async_result<R> r; std::async( r, [&]{ return x.f(); } ); with async_result being non-copyable and non-movable and ~async_result blocking on the async task, the task can store its result directly into r, without needing to allocate.

1 0

Re: [boost] [c++std-parallel-2020] Re: We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)
by Peter Dimov 14 Oct '15

14 Oct '15

Lawrence Crowl wrote: > Third, extending the use of std::future beyond its design goals caused > problems. You would expect this of any system used beyond its goals. In > particular, using std::futures for anything other than std::async was a > step too far. This is absolutely backwards. Future was always intended to be used as a generic future value. Hence the name, and the existence of 'promise'. Extending it beyond these design goals in order to imbue it with a lifetime management function caused the problems.

1 0

Test Runner Crashing
by Tom Kent 12 Oct '15

12 Oct '15

Over the weekend I've seen my windows test runner completely crashed (and other OS applications crashed as well), it is preventing the runner from getting through a complete run. I don't really have any idea where it is happening, but I have seen some errors in wserialization throwing up application crashed window...could this be related? Here's the info from the window: Problem signature: Problem Event Name: APPCRASH Application Name: test_non_intrusive_text_warchive.exe Application Version: 0.0.0.0 Application Timestamp: 561b13c0 Fault Module Name: MSVCP120D.dll Fault Module Version: 12.0.21005.1 Fault Module Timestamp: 524f8411 Exception Code: c0000005 Exception Offset: 000000000007c170 OS Version: 6.3.9600.2.0.0.272.7 Locale ID: 1033 Additional Information 1: 4de6 Additional Information 2: 4de60485dd55f55c5bf1ba0ca18762f0 Additional Information 3: 57a7 Additional Information 4: 57a7ea5113dd7a4cdeb1d88e51b65649 Read our privacy statement online: http://go.microsoft.com/fwlink/?linkid=280262 If the online privacy statement is not available, please read our privacy statement offline: C:\Windows\system32\en-US\erofflps.txt Here's the Visual Studio call stack: msvcp120d.dll!00007fff81a4c170() [Frames below may be incorrect and/or missing, no symbols loaded for msvcp120d.dll] msvcp120d.dll!00007fff819d88d2() msvcp120d.dll!00007fff819d9918() msvcp120d.dll!00007fff819e1511() > test_non_intrusive_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::_Endwrite() Line 643 + 0xcf bytes C++ test_non_intrusive_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::close() Line 341 + 0xa bytes C++ test_non_intrusive_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::~basic_filebuf<wchar_t,std::char_traits<wchar_t> >() Line 156 C++ test_non_intrusive_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t> >::~basic_ofstream<wchar_t,std::char_traits<wchar_t> >() Line 1061 + 0x13 bytes C++ test_non_intrusive_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t> >::`vbase destructor'() + 0x1c bytes C++ test_non_intrusive_text_warchive.exe!save(const char * testfile) Line 143 + 0x1b bytes C++ test_non_intrusive_text_warchive.exe!test_main(int __formal, int __formal) Line 169 C++ test_non_intrusive_text_warchive.exe!main(int argc, char * * argv) Line 203 + 0xe bytes C++ test_non_intrusive_text_warchive.exe!__tmainCRTStartup() Line 626 + 0x19 bytes C test_non_intrusive_text_warchive.exe!mainCRTStartup() Line 466 C kernel32.dll!00007fff8f7013d2() ntdll.dll!00007fff91fc5454() Any ideas? Could it be possible that too many application crashes could be taking out the test runner (and other OS applications) completely? Thanks, Tom

1 0

[Hana] Integration with the regression Matrix
by Louis Dionne 12 Oct '15

12 Oct '15

Hi, With the goal of shipping Hana with the next release of Boost, I am currently trying to satisfy the requirement that Hana's testing results show up in the Boost regression matrix. One way to achieve this would be to have Travis CI upload the results on each push to master. To do so, I would need to somehow create an XML file compatible with what the regression matrix expects. That brings up a few questions: (1) Is there a way to upload the result of CMake tests to the Boost regression matrix? I suspect something like that might have already been done as part of the (unfortunately defunct) CMake effort? (2) If not, would it be difficult to implement? Any input on how to best integrate Hana's testing results with the rest of Boost's regression testing will be greatly appreciated. Also, before someone suggests using Boost.Build: I have been looking at the possibility of maintaining a separate Jamfile. However, the need to maintain two separate build systems is annoying, so I'd like to avoid it if possible. I also think that Travis-based testing could provide a better coverage for Hana than the voluntary testers given the need for cutting edge compilers, but I could be wrong. Regards, Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Integration-with-the-regression-Mat… Sent from the Boost - Dev mailing list archive at Nabble.com.

7 9