- Boost - lists.preview.boost.org

[threads] Memory leaks in Boost threading support? Version boost_1_53_0
by Paul Morrison 14 Sep '13

14 Sep '13

I am running a number of Boost threads communicating via bounded buffers. My programs seem to run properly, but I get a number of memory leaks, usually 4- and 8- byte areas, although a few are longer. As far as I can tell, they are coming from inside Boost, as there is no mention of lines in my code. OTOH, although my code runs fine, it is quite possible that there are subtle errors in it! I am using _CRTDBG_MAP_ALLOC, which is being used correctly as it detected one area of my own that I was not freeing up, and that has been fixed. I am running VC++ 2010 Express on a 64-bit machine. Here is my memory leak display - I tried setting a few of the numbers as breakpoints, using_CrtSetBreakAlloc(), but most of them did not cause breaks. The first one broke at a new in > boost::detail::basic_condition_variable::get_wait_entry() Line 180 + 0x7 bytes C++ Why wouldn't this get freed up?! Note: <bad exception > looks ominous - where is it coming from?! Detected memory leaks! Dumping objects -> {8624} normal block at 0x02312550, 4 bytes long. Data: <HC1 > 48 43 31 02 {8615} normal block at 0x0015F8F8, 4 bytes long. Data: <h!1 > 68 21 31 02 {8602} normal block at 0x023117A0, 4 bytes long. Data: < 51 > F8 35 31 02 {5584} normal block at 0x02311760, 4 bytes long. Data: <@ > 40 F7 15 00 {4013} normal block at 0x0015F948, 4 bytes long. Data: < 1 > 00 17 31 02 {3924} normal block at 0x02314048, 4 bytes long. Data: < <1 > 20 3C 31 02 {3883} normal block at 0x02314008, 4 bytes long. Data: < +1 > D0 2B 31 02 {3862} normal block at 0x02313CA0, 4 bytes long. Data: <h!1 > 68 21 31 02 {445} normal block at 0x02314088, 4 bytes long. Data: < R1 > 88 52 31 02 {440} normal block at 0x023145F8, 4 bytes long. Data: <HC1 > 48 43 31 02 {430} normal block at 0x02314648, 4 bytes long. Data: < 51 > F8 35 31 02 {402} normal block at 0x02313FC0, 4 bytes long. Data: < 1 > 98 1D 31 02 {395} normal block at 0x023136B8, 4 bytes long. Data: < +1 > D0 2B 31 02 {382} normal block at 0x02313A18, 4 bytes long. Data: < 51 > F8 35 31 02 {355} normal block at 0x02312B90, 4 bytes long. Data: <HC1 > 48 43 31 02 {332} normal block at 0x023121E8, 4 bytes long. Data: <h > 68 F8 15 00 {316} normal block at 0x02311978, 4 bytes long. Data: <HC1 > 48 43 31 02 {298} normal block at 0x023117E0, 4 bytes long. Data: < 51 > F8 35 31 02 {270} normal block at 0x023106D0, 4 bytes long. Data: < 1 > E0 0E 31 02 {256} normal block at 0x02310C50, 4 bytes long. Data: < R1 > 88 52 31 02 {225} normal block at 0x0015FC30, 4 bytes long. Data: < > 90 F9 15 00 {217} normal block at 0x0015F5C0, 8 bytes long. Data: <l > 6C F5 15 00 00 00 00 00 {213} normal block at 0x0015E7B8, 8 bytes long. Data: < > 14 E7 15 00 00 00 00 00 {212} normal block at 0x0015E770, 8 bytes long. Data: < > EC E6 15 00 00 00 00 00 {208} normal block at 0x0015D900, 8 bytes long. Data: <\ > 5C D8 15 00 00 00 00 00 {207} normal block at 0x0015D8B8, 8 bytes long. Data: <4 > 34 D8 15 00 00 00 00 00 {203} normal block at 0x0015CA48, 8 bytes long. Data: < > A4 C9 15 00 00 00 00 00 {202} normal block at 0x0015CA00, 8 bytes long. Data: <| > 7C C9 15 00 00 00 00 00 {198} normal block at 0x0015BB90, 8 bytes long. Data: < > EC BA 15 00 00 00 00 00 {197} normal block at 0x0015BB48, 8 bytes long. Data: < > C4 BA 15 00 00 00 00 00 {193} normal block at 0x0015ACD8, 8 bytes long. Data: <4 > 34 AC 15 00 00 00 00 00 {192} normal block at 0x0015AC90, 8 bytes long. Data: < > 0C AC 15 00 00 00 00 00 {188} normal block at 0x00159E20, 8 bytes long. Data: <| > 7C 9D 15 00 00 00 00 00 {187} normal block at 0x00159DD8, 8 bytes long. Data: <T > 54 9D 15 00 00 00 00 00 {183} normal block at 0x00158F68, 8 bytes long. Data: < > C4 8E 15 00 00 00 00 00 {182} normal block at 0x00158F20, 8 bytes long. Data: < > 9C 8E 15 00 00 00 00 00 {178} normal block at 0x001580B0, 8 bytes long. Data: < > 0C 80 15 00 00 00 00 00 {177} normal block at 0x00158068, 8 bytes long. Data: < > E4 7F 15 00 00 00 00 00 {173} normal block at 0x001571F8, 8 bytes long. Data: <Tq > 54 71 15 00 00 00 00 00 {172} normal block at 0x001571B0, 8 bytes long. Data: <,q > 2C 71 15 00 00 00 00 00 {168} normal block at 0x00156340, 8 bytes long. Data: < b > 9C 62 15 00 00 00 00 00 {167} normal block at 0x001562F8, 8 bytes long. Data: <tb > 74 62 15 00 00 00 00 00 {164} normal block at 0x00155B30, 8 bytes long. Data: < Z > D4 5A 15 00 00 00 00 00 {162} normal block at 0x001559E0, 8 bytes long. Data: < Y > 84 59 15 00 00 00 00 00 {160} normal block at 0x00155890, 8 bytes long. Data: <4X > 34 58 15 00 00 00 00 00 {158} normal block at 0x00155740, 8 bytes long. Data: < V > E4 56 15 00 00 00 00 00 {156} normal block at 0x001555F0, 8 bytes long. Data: < U > 94 55 15 00 00 00 00 00 {154} normal block at 0x001554A0, 8 bytes long. Data: <DT > 44 54 15 00 00 00 00 00 {152} normal block at 0x00155350, 8 bytes long. Data: < R > F4 52 15 00 00 00 00 00 {150} normal block at 0x00155200, 8 bytes long. Data: < Q > A4 51 15 00 00 00 00 00 {148} normal block at 0x001550B0, 8 bytes long. Data: <TP > 54 50 15 00 00 00 00 00 {146} normal block at 0x00154F60, 8 bytes long. Data: < O > 04 4F 15 00 00 00 00 00 {144} normal block at 0x00154E10, 8 bytes long. Data: < M > B4 4D 15 00 00 00 00 00 {140} normal block at 0x00154C40, 16 bytes long. Data: < K > 0C 1D EF 00 02 00 00 00 01 00 00 00 88 4B 15 00 {139} normal block at 0x00154BF0, 14 bytes long. Data: <bad exception > 62 61 64 20 65 78 63 65 70 74 69 6F 6E 00 {138} normal block at 0x00154B88, 44 bytes long. Data: < h > F4 1C EF 00 00 00 00 00 68 F8 EE 00 18 F8 EE 00 {135} normal block at 0x00154A98, 16 bytes long. Data: <\ 0J > 5C 1C EF 00 02 00 00 00 01 00 00 00 30 4A 15 00 {134} normal block at 0x00154A30, 44 bytes long. Data: <D 8 > 44 1C EF 00 00 00 00 00 88 F7 EE 00 38 F7 EE 00 Object dump complete.

2 2

Forking boost's git
by Mathias Gaunard 13 Sep '13

13 Sep '13

Hi, I would have liked to fork Boost to maintain my own version with my patches before they get merged in master. I was considering using git for this, unfortunately I don't know how to make this happen with submodules. Do I need to fork each submodule separately and to edit the .gitmodules file? Is there a way to not have to do that by hand?

1 0

[COUNTERTREE + SUBALLOCATOR ] version 2.0
by Francisco José Tapia 13 Sep '13

13 Sep '13

Hi this message is to announce the version 2.0 of the *[countertree + suballocator]* library. 1 year ago I presented the request for the evaluation of the [countertree+ suballocator] version 1.0. The approval process is stopped due to the absence of review managers, and in the meanwhile I continued with the develop of this version 2.0. Actually the most important libraries and environments for parallel development, *don't provide parallel algorithms for th**e** data structures based on trees* ( set , multiset, map and multimap), and all the operations with these data structures are done with 1 thread. This is due to the difficult to divide the element of the tree between an arbitrary number of threads. (If you want to access to the element in the position 1000, you must go sequentially forward from the position 0 or sequentially backward from the last position. The [countertree + suballocator] library provide data structures set, multiset,map and multimap compatibles with the STL data structures *plus the access to the elements by their position like in a vector, and random access iterators*, You can manage it like a vector. Many parallel algorithms designed for vectors, can be used without changes with the countertree data structures. This make *easy **the **design **of **parallel algorithms* for these data structures. In the library there are a concurrent and a non concurrent versions of all the data structures. The non concurrent version are designed for to be executed inside 1 thread, or for to be accessed by several threads only in read operations (like the STL data structures), they provide a bit more speed than the concurrent version. The concurrent version is *thread safe with all the operations*, one thread can be read and other writing over the same data structure in a safe mode ( as you can see in 2.3 -examples) The concurrent library provide the full set of functions of the STL , plus an *additional set of functions*. These functions have the mission of resolve the problems appeared in the concurrent development. By example, you have a map, find an iterator from a key and with the iterator modify the element, but in the middle, other thread delete the element, and when try to access with the iterator, the program crash, and it is very difficult to reproduce the error for to debug. These additional functions make a pack with the two things, first with a read lock which permit concurrent reads, and when obtain the iterator with an exclusive lock for to modify. These additional functions *prevent the problems* like the previously described, with an *easy interface* for to understand and use for the final user. I don't know if exist any other library with tree based structures with random access iterators. I had search for and didn't find. If someone knows someone, please, say me, I am interested to know something new and collect good ideas. I suppose it don't exist because i didn't see parallel support for data structures based on trees, in any library or parallel tools. I request help to the Boost community because I am in the *moment “perhaps” *. Perhaps I forgot something, perhaps something is wrong, perhaps someone decision was not correct, perhaps it can be done in other way... *Please*, is someone see any fail, any omission, any alternative or simply any comment, please say me, in order to reach the final objective, *provide to the C++ community a good, fast, robust and reliable tool.* In my opinion, this library or other with similar functionality, is the last big part needed for to begin to think about a *concurrent STL* . You can find concurrent libraries with vectors and arrays. You have too, concurrent libraries with containers based on hash functions. With the countertree library you have concurrent set, multiset,map and multimap. The concurrent linked list can be implemented with the concurrent vector_tree ( other data structure of the library). The concurrent STL is a very big project, and must involve many agents and perspectives. From the users associations, to big computers makers and big data providers, passing by the compiler makers, the parallel tools providers... But I am sure the *Boost community* will play a central role by prestige, knowledge and experience designing libraries You can find the documentation and the code in the GitHub https://github.com/fjtapia/countertree_2.0 or you can see online in my dropbox page : https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/index.html<https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/doc/index…> If you prefer download a file with all the code and the documentation : https://github.com/fjtapia/countertree_2.0/blob/master/doc/countertree_2.0.… Sincerely yours Francisco Tapia fjtapia(a)gmail.com ** I you don't try the library, perhaps the most interested parts of the documentation is the 1.5.- Next improvements. Where explain the future parallel algorithms for the library and how they can improve others areas of the computation with the augmented trees.*

3 6

Some patches to remove obsolete MSVC version checks
by Stephen Kelly 13 Sep '13

13 Sep '13

Hi, I've created patches to remove or simplify some ifdefs for MSVC versions which are now obsolete. There are many more to do. http://www.steveire.com/msvc_obsolete_versions_patches This is a followup to this thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/243094 (Removing old config macro and increasing compiler requirements., 2013-07-29) The patches are most easily applied locally and reviewed with a git-svn checkout and git am. I'll also apply to get SVN access so I can commit patches myself. Thanks, Steve.

1 0

[asio] boost::asio::async_connect reports success on failure
by Ben Pope 13 Sep '13

13 Sep '13

Hi all, I've found a regression between 1.53 to 1.54; if you compile boost/libs/asio/example/cpp11/chat/chat_client.cpp and point it at a host and port that doesn't exist or refuses the connection, instead of coming back with an error, such as host not found or connection refused, it reports success (on the conversion to bool). (you might want to embellish the example with a std::cout << error_code.message() << std::endl;) This appears to be the case across Linux, Darwin, iOS and Android :( synchronous connect seems to work correctly (i.e., echo/blocking_tcp_echo_client.cpp) Ben

2 4

Removing old config macro and increasing compiler requirements.
by Stephen Kelly 12 Sep '13

12 Sep '13

Hi there, I've been working on the modularization effort from a CMake point of view, and from an 'actual modularization' point of view, looking at interdependencies: http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/9/focus=26 I'd like to start on reducing interdependencies, and I'd like to start reasonably small, as no-one in the boost community knows me and see how it goes from there. I'm very active in CMake, Qt and KDE. Currently, in the modularized boost repos, boost::config and boost::core depend on each other. I listed 3 ways of fixing this on the ryppl list: http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201 My preference is the removal of BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS, and requiring compilers to have the feature. That way boost/config/suffix.hpp will no longer need to include boost/{non_,}type.hpp. My preference is increasing the compiler requirement, because that may open up more similar opportunities for reducing dependencies and interdependencies throughout boost. Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0. Comments? Thanks, Steve.

15 82

proposal for metafunction mpl::eval
by klaus triendl 12 Sep '13

12 Sep '13

Hi, I'm not so much into meta-programming, so I'm not sure whether there's already an alternative available. Nevertheless I'd like to propose a new metafunction that simply evaluates its argument: template<typename F> struct eval: F::type {}; I've found it somehow useful because it avoids syntactical sugar when specifying a condition to be evaluated for eval_if: eval_if< eval<apply<UnaryF, Arg>>, F1, F2 >; instead of writing: eval_if< typename apply<UnaryF, Arg>::type, F1, F2 >; Any comments on this? -- klaus triendl

4 6

[interprocess] Different processes accessing shared memory in different locations
by Tom Sanham 11 Sep '13

11 Sep '13

Hi Our application has the following scenario using Boost V1.0.52: 1) Process A writes to boost interprocess shared memory. The files appear at C:\ProgramData\boost_interprocess\... 2) Process A launches Process B 3) Process B attempts to read from shared memory but fails. It is attempting to read from: C:\Users\<username>\AppData\Local\Temp\boost_interprocess\... This failure only occurs on one single Windows 8 64 bit machine out of many we have tested. On all other machines, the application works perfectly. Please could somebody advise: What changes to our application could be made to avoid this? What changes to the machine's configuration (eg. Registry) could be made to avoid this issue? Many thanks Thomas Sanham

3 4

[asio] Mixing streambuf-based async_read and async_read_until
by Gavin Lambert 11 Sep '13

11 Sep '13

I was tracing through some code today (using Boost.Asio 1.53) and noticed something that seems a little odd to me. Given a boost::asio::streambuf that already contains data (typically from a previous read), the async_read_until operation will check the buffer first to see if it can find the specified delimiter already, and will only fetch more data from the stream if it needs to. It does appear to perform at least one async_read_some per async_read_until call, but this will be a zero-length-read that will not actually hit the network/wherever. (Could probably be optimised a little further though.) The async_read operation however will not check the buffer. While it won't destroy any existing data (it just appends) it will still fetch additional data from the stream up to the specified completion condition, ignoring however much is already in the buffer. For example, if buf already contains 32 unconsumed bytes then async_read(s, buf, transfer_exactly(16), cb) will fetch 16 more bytes from the network, leaving 48 bytes in the buffer but only passing 16 to the read handler. Of particular note is that it will wait for those 16 bytes to be read from the network -- it's not satisfied with the data it already has. The net effect of these behaviours I think is that if you're using async_read_until exclusively or async_read exclusively then everything will behave fairly normally. If you are mixing these two operations on the same stream then you will either be losing data (if you use separate streambufs) or reading more data than you should (if you use the same streambuf and don't check outside of ASIO to see if it already contained enough data). Maybe it's just me, but I find it surprising that async_read doesn't check if the supplied streambuf already satisfies the completion condition, given that async_read_until does and the docs for async_read do say that it's allowed to make zero async_read_some calls. Is this a bug or is it expected behaviour?

1 0

Incompatible Boost license file in boost.container
by Philip Bennefall 10 Sep '13

10 Sep '13

Hi all, I was looking at boost.container, and found that boost/container/deque.hpp has similar problems as boost/detail/endian.hpp had before that was fixed. Parts of deque.hpp seem to be covered by a license that is not compatible with the Boost software license. I quote: // Copyright (c) 1996,1997 // Silicon Graphics Computer Systems, Inc. // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appear in all copies and // that both that copyright notice and this permission notice appear // in supporting documentation. Etc. Kind regards, Philip Bennefall

4 4