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

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

[accumulator] std::chrono::duration in boost::accumulator
by georg＠schorsch-tech.de 12 Feb '17

12 Feb '17

I want to build a histogram of `std::chrono::high_resolution_clock::duration` object. For this issue i wanted to use boost::accumulators as the framework. As it did not compile in my project i teared it down and based it on a running example with `double` as a data type. My general goal on my project is to do use for everything united types. Time and all measured stuff. I would want to avoid to use `.count()` on the duration. Is there any known workaround around this? it is not dependent on the compiler as it seems. With gcc 6.3 it failes too. It compiles when i use clang++-3.9 --std=c++14 -g -O0 main.cpp But when i set the define USE_CHRONO it failes with the error: clang++-3.9 --std=c++14 -g -O0 -DUSE_CHRONO main.cpp In file included from main.cpp:7: /usr/include/boost/accumulators/statistics/density.hpp:75:15: error: no matching constructor for initialization of 'array_type' (aka 'vector<std::chrono::duration<unsigned long, std::ratio<1, 1000000000> > >') , samples_in_bin(num_bins + 2, 0.) ^ ~~~~~~~~~~~~~~~~ and here is my teared down example. I used this site as a base and exhanged double to data_t. http://programmingexamples.net/wiki/CPP/Boost/Histogram #include <vector> #include <algorithm> #include <iostream> #include <chrono> #include <boost/accumulators/accumulators.hpp> #include <boost/accumulators/statistics/density.hpp> #include <boost/accumulators/statistics/stats.hpp> using namespace boost; using namespace boost::accumulators; using duration_t = std::chrono::high_resolution_clock::duration; #ifdef USE_CHRONO using data_t = duration_t; data_t construct(double d) { return std::chrono::milliseconds(0); } #else using data_t = double; data_t construct(double d) { return d; } #endif using acc = accumulator_set<data_t, features<tag::density> >; using histogram_type = iterator_range<std::vector<std::pair<data_t, data_t> >::iterator >; template <typename T> class data_filler { public: data_filler(){} T operator()() { return rand()/(T)RAND_MAX; } }; template <> class data_filler<duration_t> { public: data_filler(){} duration_t operator()() { return std::chrono::milliseconds(rand()/RAND_MAX); } }; int main(int argc, char** argv) { //create some random data std::vector<data_t> data(100); std::generate(data.begin(), data.end(), data_filler<data_t>()); int c = data.size();//cache size for histogramm. //create an accumulator acc myAccumulator( tag::density::num_bins = 20, tag::density::cache_size = 10); //fill accumulator for (int j = 0; j < c; ++j) { myAccumulator(data[j]); } auto hist = density(myAccumulator); data_t total = construct(0.0); for( int i = 0; i < hist.size(); i++ ) { // std::cout << "Bin lower bound: " << hist[i].first << ", Value: " << hist[i].second << std::endl; total += hist[i].second; } //std::cout << "Total: " << total << std::endl; //should be 1 (and it is) return 0; }

1 0

boost::icl::contains question
by Sanchay Harneja 09 Feb '17

09 Feb '17

Hi, boost::icl::interval_map<int, boost::icl::interval_map<int, boost::icl::interval_set<int>>> larger, smaller; larger.add(make_pair(boost::icl::discrete_interval<int>::closed(102,104), boost::icl::interval_map<int, boost::icl::interval_set<int>>{ make_pair(boost::icl::discrete_interval<int>::closed(0,0), boost::icl::interval_set<int>{boost::icl::discrete_interval<int>::closed(2,4)})})); smaller.add(make_pair(boost::icl::discrete_interval<int>::closed(103,103), boost::icl::interval_map<int, boost::icl::interval_set<int>>{ make_pair(boost::icl::discrete_interval<int>::closed(0,0), boost::icl::interval_set<int>{boost::icl::discrete_interval<int>::closed(3,3)})})); cout << larger << endl; cout << smaller << endl; cout << boost::icl::contains(larger, smaller) << endl; cout << ((smaller & larger) == smaller) << endl; As given above, I'm trying to check if smaller is subset of larger. But I get following output: {([102,104]->{([0,0]->{[2,4]})})} {([103,103]->{([0,0]->{[3,3]})})} 0 1 Any reason why boost::icl::contains(larger, smaller) doesn't work but ((smaller & larger) == smaller) works? Thanks.

1 0