February 2017 - Boost-users - lists.preview.boost.org

[bip] alignment/padding differs
by Jan Boehme 23 Feb '17

23 Feb '17

Hi, I'm using interprocess to share mem between different processes. Unfortunately these processes were built using different compiler version (gcc3, gcc4, gcc5) and we're seeing different alignment or padding dependent on which run-time was in charge of creating the mapped files. Of course we used the same boost version (1.60) while creating the binaries. Obviously ip can't handle these different layouts and mostly runs in indefinite loops while traversing an rb-tree not finding the first shm object. Are there any template parameters that enable the code to be accessed using different run times through forcing the same layout? Thanks a lot, Jan.

2 2

Using Boost 1.63 on Windows with FindBoost.cmake
by csiga.biga＠aol.com 22 Feb '17

22 Feb '17

Does anyone have a working installation of Boost 1.63 on Windows that FindBoost.cmake can be instructed to find? I tried with both a custom build (for MSMPI mostly) that it failed to find the libraries of, and after reading through FindBoost.cmake, I saw it is dominantly tailored towards the prebuilt binaries (at least on Windows), so I grabbed that, I set BOOSTROOT to the installation root, but it still fails to find Boost::chrono I got find_package(Boost 1.63 REQUIRED COMPONENTS chrono) include_directories(${Boost_INCLUDE_DIRS}) in my top-level CMakeLists.txt file, as all of my targets depend on chrono, and after that I use target_link_libraries (${declare_trisycl_test_TARGET} $<$<BOOL:USES_OPENCL>:${OpenCL_LIBRARIES}> $<$<NOT:$<BOOL:WIN32>>:Threads::Threads> Boost::chrono) On the command-line this is what I get at configure time: CMake Error at C:/Kellekek/Kitware/CMake/3.8.0/share/cmake-3.8/Modules/FindBoost.cmake:1812 (message): Unable to find the requested Boost libraries. Boost version: 1.63.0 Boost include path: C:/Kellekek/Boost/1.63.0-prebuilt Could not find the following Boost libraries: boost_chrono Some (but not all) of the required Boost libraries were found. You may need to install these additional Boost libraries. Alternatively, set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. Call Stack (most recent call first): CMakeLists.txt:26 (find_package) As far as FindBoost.cmake goes, it seems to know chrono for 1.63. So how should this work?

2 1

Re: [Boost-users] [Boost.Test] Using intel MKL instead of ACML with the boost testing framework
by anandram sundar 21 Feb '17

21 Feb '17

Sending this again, since I hadnt subscribed before sending this email. One suspicious candidate from further debugging is the results_collector singleton(just because it appears in the stack and because its a singleton) On Tue, Feb 21, 2017 at 2:03 PM, anandram sundar <sundaranandram(a)gmail.com> wrote: > Hi, > I recently wrote some tests using the Boost testing framework and > everything was working fine until I used the intel MKL with my project. As > soon as I started linking these libraries, the tests started failing with a > segmentation fault. This happens after the test execution is done and when > the cleanup is happening. Looking at what valgrind outputs, it seems like > there is some memory being released which is invalid(not sure if it is > because of calling free on already freed memory). This actually happens > even if none of the code depends on the MKL. Just adding them to the linked > libraries is enough to cause this. > > GCC 4.9.3 > Boost ver 1.62 > > *==85160== Invalid read of size 4* > *==85160== at 0x10916C57: std::basic_string<char, > std::char_traits<char>, std::allocator<char> >::~basic_string() (in > /lib/libstdc++.so.6.0.20)* > *==85160== by 0x1104AEBC: __cxa_finalize (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== by 0x41981E2: ??? (in > /lib/libboost_unit_test_framework.so.1.62.0)* > *==85160== by 0x400EC5B: _dl_fini (in /lib64/ld-2.12.so > <http://ld-2.12.so>)* > *==85160== by 0x1104AB21: exit (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== by 0x11033D63: (below main) (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== Address 0x1262fab0 is 16 bytes inside a block of size 30 > free'd* > *==85160== at 0x4C26FD6: operator delete(void*) > (vg_replace_malloc.c:480)* > *==85160== by 0x1104AB21: exit (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== by 0x11033D63: (below main) (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > > > *==85160== Invalid free() / delete / delete[] / realloc()* > *==85160== at 0x4C26FD6: operator delete(void*) > (vg_replace_malloc.c:480)* > *==85160== by 0x1104AEBC: __cxa_finalize (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== by 0x41981E2: ??? (in > /lib/libboost_unit_test_framework.so.1.62.0)* > *==85160== by 0x400EC5B: _dl_fini (in /lib64/ld-2.12.so > <http://ld-2.12.so>)* > *==85160== by 0x1104AB21: exit (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== by 0x11033D63: (below main) (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== Address 0x1262faa0 is 0 bytes inside a block of size 30 free'd* > *==85160== at 0x4C26FD6: operator delete(void*) > (vg_replace_malloc.c:480)* > *==85160== by 0x1104AB21: exit (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > *==85160== by 0x11033D63: (below main) (in /lib64/libc-2.12.so > <http://libc-2.12.so>)* > > > I am not sure why this is happening. Are there any known compatibility > issues between MKL and Boost testing framework. I was using ACML before > this and the tests were working fine with them. > > > Thanks, > Anand >

1 0

[iostreams] filtering streams in a chain are continually writing the same bytes
by Andrew Ames 21 Feb '17

21 Feb '17

Perhaps someone can clarify that my use of multichar_output_filter is valid. When I debug this, even though my write method is returning 4 bytes for every write, the caller of my output filter keeps providing me the same four bytes after the first sequence of 4 bytes. This is boot version 1.62. Here is compiling code that illustrates: class fixed_size_output_filter : public boost::iostreams::multichar_output_filter { public: fixed_size_output_filter(std::streamsize size = 4) : mSize(size) {} template<typename Sink> std::streamsize write(Sink &sink, const char *s, std::streamsize n) { std::streamsize bytesAttempted = std::min(mSize, n); std::streamsize bytesActual = boost::iostreams::write(sink, s, bytesAttempted); return bytesActual; } private: std::streamsize mSize; }; BOOST_AUTO_TEST_CASE(FixedSizeOutputFilter) { #define BYTES 500 char sink_buffer[BYTES]; array_sink array_sink(sink_buffer, sizeof(sink_buffer)); std::streampos os_pos; { filtering_ostream os; os.push(fixed_size_output_filter()); os.push(array_sink); char buffer[BYTES]; for(char i = 0; i < sizeof(buffer); i++) buffer[i] = i; os.write(buffer, sizeof(buffer)); } for(char i = 0; i < sizeof(sink_buffer); i++) BOOST_CHECK(i == sink_buffer[i]); } The actual bytes that end up in the sink_buffer are as follows: 0, 1, 2, 3, 4, 5, 6, 7, 4, 5, 6, 7, 4, 5, 6, 7, 4, 5, 6, 7, ....uninitialized bytes follow through the rest of the buffer. It would appear that the indirect_streambuf in use by the filter chain is incorrectly flushing the bytes. Is my understanding of the library flawed? Does this appear to be a bug? Any help is greatly appreciated. -- Andrew Ames aames(a)tanzle.com

1 1

[thread] Ambiguity in variadic wait_for_all
by Gavin Lambert 18 Feb '17

18 Feb '17

A colleague recently ran into an interesting issue when upgrading some working code from Boost 1.55 to 1.60/1.63 (and from C++03 to C++11). The exact details are unimportant, but it was trying to get the address of boost::wait_for_all(Iterator, Iterator), for use in a Boost.Bind call. In 1.55, this worked fine, although of course it had to supply template parameters that proved the parameters were not futures (thus causing enable_if<is_future_type<F1>> to fail, disabling the two-future-args overload of the function. In 1.60/1.63, the variadic method is encountered instead, which lacks any enable_if condition and thus the ambiguity between the two remains and the compiler errors out. (When calling it directly, the variadic one manages to get disabled as long as the iterator type lacks a wait() method, but this doesn't apply when just getting the method address, as it's not part of the signature.) Should the variadic form also have enable_if? Or is this considered user error for trying to use Bind in a variadic-compatible compiler instead of using a lambda?

2 3

Scheduled Outage : Web sites / Trac
by Michael Caisse 17 Feb '17

17 Feb '17

We are planning the final move of services from IU this week. Expect service outages for all web sites including Trac on 17-February-2017 between 16:00 UTC - 00:00 UTC. The mail lists will continue to operate during this time; however, all other sub-domains for boost.org will be affected. Sync'ing bandwidth with IU has been low recently and has caused us to increase the outage window. We will notify these lists when services are available again. Thank you for your patience during the move. -- Michael Caisse Ciere Consulting ciere.com

1 1

type() Segmentation Fault
by Samuel Jiménez Gil 16 Feb '17

16 Feb '17

Hi, I've got a very strange segmentation error that stems from calling type() method in any class. Surprisingly, this only occurs in another compilation that I have where I link with other gnu libraries. In both cases I am compiling with -std=c++11 and cygwin32. Is anybody aware of type() method conflicting with other libraries? Many thanks. Best regards. -- Samuel Jiménez Gil. Ph.D. Student Real-Time Systems Group, Department of Computer Science University of York Heslington York, UK YO10 5GH Email disclaimer: http://www.york.ac.uk/docs/disclaimer/email.htm

1 0

[test] bitwise checks for non-integer types
by Norbert Wenzel 14 Feb '17

14 Feb '17

I was just surprised that BOOST_CHECK_BITWISE_EQUAL does not simply take two memory ranges and compares them bitwise, but requires integers (or types that support bit shifting). I wanted to compare two floats after binary deserialization and wanted to make sure all bits had been placed correctly, before doing value comparison. What I came up with now is a reinterpret_cast to uint8_t* and then using bitwise comparison byte for byte. I would have expected the test framework to do exactly that internally. Is comparing anything besides integers bitwise considered a bad practice or is there another reason for this limitation of BITWISE_EQUAL? If there is a rationale could that be documented at [0], since the documentation currently only speaks of unconstrained "values". thanks, Norbert [0] http://www.boost.org/doc/libs/1_63_0/libs/test/doc/html/boost_test/utf_refe…

2 2

[serialization]: Possible to not escape double quotes
by Forumer 4umer 14 Feb '17

14 Feb '17

Hello, I am using boost serialization to save some parameteres into an xml file but this xml file is parsed through gettext tools to generate translations. The macro used for generations is _("") so my xml should look like this: <ProcedureSchema> <procedures class_id="4" tracking_level="0" version="0"> <count>1</count> <item_version>0</item_version> <item> <Name>_("Full procedure")</Name> </item> </procedures> </ProcedureSchema> The problem is boost serialization escapes double quotes with " : <Name>_("Full procedure")</Name> Would it be possible to not escape double quotes ? or at least provide a parameter that allows it ?

2 1

Boost.Log and reinitializing text file backend on I/O errors
by Tero Saarni 13 Feb '17

13 Feb '17

Hi, I'm using text file sink to log into a file on NFS filesystem. I would like to make logging more robust when it comes to unreliability of NFS. I've registered an exception handler to ignore I/O errors, but I don't know how to re-open the log file automatically so that logging would continue when the filesystem is online again. My first try was to remove and reinitialize all sinks when the exception handler is called, but this seems to cause deadlock. Is there a way to simply re-open the associated file which caused the exception? -- Tero

1 0