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

[BGL] memory leak in graph/r_c_shortest_paths.hpp
by potato_research 24 Sep '13

24 Sep '13

Hello, I'm using BGL in my project and, with some input data, I get - sooner or later, as I run r_c_shortest_paths many times - a segfault. This behaviour is apparently quite random, as I can see by implementing a custom visitor that the last label evaluated before the crash changes all the time. I must also say that the graph I use, while always having the same topological structure, has different properties that affect labelling each time I run the algorithm and these vary quite randomly from one run to the other, as they are generated by a random heuristics. Anyway, with one particular set of input data, I manage to have the program segfault (as I said, sooner or later) 100% of the times. This is far from being an MWE, but it's the best I could produce. I tried to debug the memory leak with valgrind and it turns out that r_c_shortest_paths_dispatch is trying to access memory in a block previously freed by: l_alloc.deallocate( cur_outer_splabel.get(), 1 ); in r_c_shortest_paths.hpp:314. After some debugging I started to believe that the problem doesn't rely with my code, but it might be a bug in r_c_shortest_paths.hpp. If this is actually the case and where the problem lies, though, I haven't been able to figure out with certainty. The output from valgrind can be found here: http://pastebin.com/raw.php?i=WWafwFv3 (output cleaned up and with templates substituted) http://pastebin.com/raw.php?i=cb3p6jzM (raw output intended to facilitate reading and with templates substituted) http://pastebin.com/raw.php?i=qeauBQTm (raw output indented to facilitate reading) http://pastebin.com/raw.php?i=hpppf49c (raw output) My code (the whole project) can be found here: https://github.com/alberto-santini/maritime-vrp In order to run it, one must have a licensed copy of CPLEX and change the include and library paths in the Makefile's accordingly. Unfortunately, without putting the labelling part inside a price-and-branch procedure (that uses CPLEX as a solver for the master problem) I wasn't able to produce input data by hand that would lead me to obtain the segfault. I understand this is not the best way to investigate into a bug and will be happy to provide any further help if requested to. Thanks, AS -- View this message in context: http://boost.2283326.n4.nabble.com/BGL-memory-leak-in-graph-r-c-shortest-pa… Sent from the Boost - Users mailing list archive at Nabble.com.

2 4

BJAM and VS2013RC
by LeMay.Steve 23 Sep '13

23 Sep '13

Has anyone successfully built Boost 1.54 with VS2013RC? Did you have an issue with the build process locating cl ? Steven LeMay Game Platform Engineering International Game Technology 9295 Prototype Way Reno, NV 89521 Office: +1 775.448.8089 Mobile: +1 775.813.6676 steven.lemay(a)igt.com<mailto:steven.lemay@igt.com> This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Any humorous implications are purely the result of misinterpretations provided by the reader.

6 7

Re: [Boost-users] [boost] cross-compilation x86_64-w64-ming32: undefined reference to `InterlockedIncrement'
by Frédéric Bron 23 Sep '13

23 Sep '13

> I probably missed the original problem, but the patch doesn't look correct > to me. The section guarded with "defined( BOOST_MSVC ) || defined( > BOOST_INTEL_WIN )" is obviously targeted for compilers supporting > interlocked intrinsics, which gcc isn't. MinGW should probably be handled > by the last section of the #if/elif/endif sequence. Anyway, what problem > are you trying to fix? Here is what I get when build an application with boost and mingw-w64 targeting x86_64: /usr/x86_64-w64-mingw32/sys- root/mingw/lib/../lib/libboost_thread-mt.a(thread.o):(.text+0x286): undefined reference to `InterlockedIncrement' /usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libboost_thread-mt.a(thread.o):(.text+0x3e7): undefined reference to `InterlockedDecrement' /usr/lib64/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld: /usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libboost_thread-mt.a(thread.o): bad reloc address 0x8 in section `.data' I have been able to solve this by defining BOOST_USE_WINDOWS_H but this creates issues with Unicode when I also use wxWidgets. The patch proposed solves the issue. I recognise that I say that gcc should be considered as MSVC with regards to these Interlocked things which I do not understand. It may seem strange but it works. What's wrong with it? Basically, I just #include <intrin.h>; what's wrong with that? Frédéric

1 0

Re: [Boost-users] cross-compilation x86_64-w64-ming32: undefined reference to `InterlockedIncrement'
by Frédéric Bron 23 Sep '13

23 Sep '13

So I eventually managed to fix the issue with interlocked.hpp and mingw-w64: both i686 and x86_64 now work. Attached is a patch against 1.54.0. Is it possible to include this in 1.55.0? Regards, Frédéric

1 0

Multiple instance of options
by Ulf Samuelsson 23 Sep '13

23 Sep '13

Need to parse an "ini" file which configures one or more sensors. The sensors can be of the same type and are identified by "name", "type" and an "id" Some configuration items are for all sensors Other configuration tiems are only for some sensors. [sensor] SensorName="Outdoor Temp" SensorType=1 # Temp Sensor SensorID=1000 SerialNumber="12344" Active=1 Device="/dev/ttyUSB01" [sensor] SensorName="Indoor Temp" SensorType=1 # Temp Sensor SensorID=1001 SerialNumber="12345" Active=1 Device="/dev/USB02" [sensor] SensorName="Light" SensorType=2 # Light Sensor SensorID=1002 SerialNumber="12349" Active=1 Device="/dev/ttyUSB02" MaxLumen="500" Is having multiple identical section names possible with boost program options? It is of course possible to do [sensor_1] ... [sensor_2] ... [sensor_3] ... but that is not so nice looking, and you get a hard limit on the number of sensors you can attach. Ideas? BR Ulf Samuelsson

3 3

Question about boost.build and automatic selection of toolsets
by Mauricio Carneiro 22 Sep '13

22 Sep '13

I am using boost-build in my project (very happy with the outcome) but I would like to have the toolset selected automatically based on the operating system. Currently I am running successfully from the command line by manually setting the toolset when I am running it from macos and linux accordingly, but I feel like the Jamroot file should be able to figure that out for me. Any ideas? I made a more descriptive post on stack overflow, to share the knowledge once we figure this one out. http://stackoverflow.com/questions/18939911/choosing-compiler-options-based… Thank you, Mauricio Carneiro, Ph.D. http://www.broadinstitute.org/~carneiro/

2 1

units
by Robert Ramey 22 Sep '13

22 Sep '13

I have a program in which there is the notion of consumption rate such as m^3/sec, gallons/hour, etc. I have consumption_rate unit defined in terms of si units. I read in a quanity in gallons/hour and so far so good. If I display the quantity it is displayed as m^3/sec. This displays the "compound units" as expected - very cool. All this is OK as far as it goes. When I try to display the quantity as gallons/hour again I have a whole host of problems. The attached test fill illustrates the issues. The only way I've been able to do is is by making a complete end run around the units system itself - sort of self defeating. I would appreciate insight anyone might be able to offer into this issue. Robert Ramey begin 666 test_units.cpp M#0HC:6YC;'5D92 \:6]S=')E86T^#0H-"B-I;F-L=61E(#QB;V]S="]U;FET M<R]I;RYH<' ^#0HC:6YC;'5D92 \8F]O<W0O=6YI=',O<&]W+FAP<#X-"B\O M(VEN8VQU9&4@/&)O;W-T+W5N:71S+V1E=&%I;"]U=&EL:71Y+FAP<#X-"B-I M;F-L=61E(#QB;V]S="]U;FET<R]S>7-T96US+V-G<RYH<' ^#0HC:6YC;'5D M92 \8F]O<W0O=6YI=',O<WES=&5M<R]S:2YH<' ^#0HC:6YC;'5D92 \8F]O M<W0O=6YI=',O<WES=&5M<R]S:2]I;RYH<' ^#0H-"B-I;F-L=61E(#QB;V]S M="]U;FET<R]B87-E7W5N:71S+VUE=')I8R]H;W5R+FAP<#X-"@T*=7-I;F<@ M;F%M97-P86-E(&)O;W-T.CIU;FET<SL-"@T*+R\@9&5R:79E('-P96-I86P@ M=6YI=',@=&AA="!W92!U<V4@:6X@;W5R(&%P<&QI8V%T:6]N#0HO+R!D97)I M=F5D(&1I;65N<VEO;B!F;W(@8V]N<W5M<'1I;VY?<F%T92 Z($T@5%XM,0T* M='EP961E9B!B;V]S=#HZ=6YI=',Z.F1E<FEV961?9&EM96YS:6]N/ T*(" @ M(&)O;W-T.CIU;FET<SHZ;&5N9W1H7V)A<V5?9&EM96YS:6]N+#,L#0H@(" @ M8F]O<W0Z.G5N:71S.CIT:6UE7V)A<V5?9&EM96YS:6]N+"TQ#0H^.CIT>7!E M(&-O;G-U;7!T:6]N7W)A=&5?9&EM96YS:6]N.R @(" @(" @(" @(" @(" - M"@T*='EP961E9B!B;V]S=#HZ=6YI=',Z.G5N:70\#0H@(" @8V]N<W5M<'1I M;VY?<F%T95]D:6UE;G-I;VXL#0H@(" @8F]O<W0Z.G5N:71S.CIS:3HZ<WES M=&5M#0H^(&-O;G-U;7!T:6]N7W)A=&5?=6YI=#L-"G1Y<&5D968@8F]O<W0Z M.G5N:71S.CIQ=6%N=&ET>3QC;VYS=6UP=&EO;E]R871E7W5N:70L(&9L;V%T M/B!C;VYS=6UP=&EO;E]R871E.PT*#0HC:6YC;'5D92 \8F]O<W0O=6YI=',O M8F%S95]U;FET<R]U<R]G86QL;VXN:'!P/@T*='EP961E9B!B;V]S=#HZ=6YI M=',Z.G5S.CIG86QL;VY?8F%S95]U;FET.CIU;FET7W1Y<&4@9V%L;&]N7W5N M:70[#0I"3T]35%]53DE44U]35$%424-?0T].4U1!3E0H9V%L;&]N+"!G86QL M;VY?=6YI="D[(" @( T*0D]/4U1?54Y)5%-?4U1!5$E#7T-/3E-404Y4*&=A M;&QO;G,L(&=A;&QO;E]U;FET*3L@(" @#0H-"B-I;F-L=61E(#QB;V]S="]U M;FET<R]B87-E7W5N:71S+VUE=')I8R]H;W5R+FAP<#X-"G1Y<&5D968@8F]O M<W0Z.G5N:71S.CIM971R:6,Z.FAO=7)?8F%S95]U;FET.CIU;FET7W1Y<&4@ M:&]U<E]U;FET.PT*0D]/4U1?54Y)5%-?4U1!5$E#7T-/3E-404Y4*&AO=7)S M+"!H;W5R7W5N:70I.PT*0D]/4U1?54Y)5%-?4U1!5$E#7T-/3E-404Y4*&AO M=7(L(&AO=7)?=6YI="D[(" @( T*#0II;G0@;6%I;B@I#0I[#0H@(" @<75A M;G1I='D\8V]N<W5M<'1I;VY?<F%T95]U;FET/B @0R@Q+C @*B!G86QL;VX@ M+R!H;W5R*3L-"@T*(" @('-T9#HZ8V]U=" \/" Q+C @*B!G86QL;VYS("\@ M:&]U<B \/" B("T@;VL@9&ES<&QA>7,@9V%L+VAO=7(B(#P\('-T9#HZ96YD M;" [#0H@(" @<W1D.CIC;W5T(#P\($,@/#P@(B M(&]K/R!D:7-P;&%Y<R!M M,R]S96,B(#P\('-T9#HZ96YD;" [#0H@(" @<W1D.CIC;W5T(#P\($,@*B!G M86QL;VYS("\@:&]U<B \/" B("T@;F]T(&]K("T@22!M:6=H="!B=7D@=&AI M<R(@/#P@<W1D.CIE;F1L(#L-"B @("!S=&0Z.F-O=70@/#P@0R O("AG86QL M;VYS("\@:&]U<BD@/#P@(B M(&)U="!T:&5N('1H:7,@<VAO=6QD('=O<FLA M(B \/"!S=&0Z.F5N9&P@.PT*#0H@(" @<W1D.CIC;W5T(#P\($,N=F%L=64H M*2 O("AG86QL;VYS("\@:&]U<BD@/#P@(B M(&1I<W!L87ES(&@O9R M3TL_ M(&)U="!U;F5X<&5C=&5D('9A;'5E("$@*&5X<&5C=&5D(#$N,"D@(CP\('-T M9#HZ96YD;" [#0H@(" @+R\@<W1D.CIC;W5T/#P@0RYV86QU92@I("\@*&=A M;&QO;G,@+R!H;W5R*2YV86QU92@I(#P\("(@+2!D:7-P;&%Y<R!H+V<@+4]+ M/R!B=70@=6YE>'!E8W1E9"!V86QU92 A("AE>'!E8W1E9" Q+C I("(\/"!S M=&0Z.F5N9&P@.PT*(" @('-T9#HZ8V]U=" \/"!#+G9A;'5E*"D@+R H*#$N M," J(&=A;&QO;G,I("\@*#$N," J(&AO=7(I*2YV86QU92@I(#P\("(@+2!U M;F5X<&5C=&5D('9A;'5E("$@*&5X<&5C=&5D(#$N,"D@(CP\('-T9#HZ96YD M;" [#0H@(" @<W1D.CIC;W5T(#P\($,N=F%L=64H*2 O("@H,2XP("H@9V%L M;&]N<RDN=F%L=64H*2 O("@Q+C @*B!H;W5R*2YV86QU92@I*2 \/" B("T@ M=6YE>'!E8W1E9"!V86QU92 A("AE>'!E8W1E9" Q+C I("(\/"!S=&0Z.F5N M9&P@.PT*#0H@(" @9FQO870@9R ]("@Q+C @*B!G86QL;VYS*2YV86QU92@I M.PT*(" @('-T9#HZ8V]U=" \/"!G(#P\('-T9#HZ96YD;#L-"B @("!F;&]A M="!H(#T@*#$N," J(&AO=7(I+G9A;'5E*"D[#0H@(" @<W1D.CIC;W5T(#P\ M(&@@/#P@<W1D.CIE;F1L.PT*(" @(&9L;V%T('(@/2!#+G9A;'5E*"D@+R H M9R O(&(a)I.PT*(" @('-T9#HZ8V]U=" \/"!R("H@9V%L;&]N<R O(&AO=7(@ M/#P@(B M(&9I;F%L;'DA('1H92!C;W)R96-T(')E<W5L="$B(#P\('-T9#HZ M96YD;#L-"@T*(" @('-T9#HZ8V]U=" \/"!S=&0Z.F5N9&P[#0H@(" @#0H@ M(" @<75A;G1I='D\<VDZ.F%R96$^(" @(" @02@Q+C4J<VDZ.FUE=&5R*F-G M<SHZ8V5N=&EM971E<BD[#0H@(" @#0H@(" @<W1D.CIC;W5T(#P\(#$N-2IS M:3HZ;65T97(J8V=S.CIC96YT:6UE=&5R(#P\('-T9#HZ96YD; T*(" @(" @ M(" @(" @(" \/"!!(#P\('-T9#HZ96YD; T*(" @(" @(" @(" @(" \/"!S A=&0Z.F5N9&P[#0H-"B @("!R971U<FX@,#L-"GT-"@T* ` end

2 3

Boost::Bind Problem
by vishal rawate 22 Sep '13

22 Sep '13

Hello, I am trying to use Boost::Bind to bind my function but I am getting an error as Bind cannot diffrentiate between the constructors even though they have diffrent function signatures. TestBind(boost::bind((&Test::process), &t1, _1)); I would highly appreciate any help. Thanks //Boost Includes #include <boost/function.hpp> #include <boost/bind.hpp> #include <boost/enable_shared_from_this.hpp> namespace test{ struct A{ public: int one; int two; }; struct B{ public: short three; short four; }; typedef boost::shared_ptr<A> t_boostInt; typedef boost::shared_ptr<B> t_boostShort; class TestBind{ public: typedef boost::function< int (t_boostInt)> t_ProcessFunctionInt; public: ///< call back process function for short typedef boost::function< short (t_boostShort)> t_ProcessFunctionShort; public: TestBind( t_ProcessFunctionInt func){} TestBind(t_ProcessFunctionShort func){} }; class Test { public: Test(){} ~Test(); public: int process(t_boostInt msg) { return 1;} }; int main(int argc, char * argv[]) { try { Test t1; TestBind(boost::bind((&Test::process), &t1, _1)); } catch (std::exception & exception) { std::cout << exception.what() << std::endl; } return 0; } }

3 4

Newbie boost::spirit rule semantic action question
by LeMay.Steve 21 Sep '13

21 Sep '13

Brand-newbie boost::spirit::qi question. MSVS2012, boost 1.54 I have a response from a serial device that provides with 0 or more "profiles" in a given character format. I want to capture the number of profile responses in the list (semantic action) as well as have the value into the final result (std::vector<std::string>). How do I properly express this? Given the input.... (in this case, there are zero profiles returned) *ARSS:0<CR><LF>OK<CR><LF> Expect a vector of strings containing "*ARSS" "0" "OK" This sub-rule fails to return... (Not failing to parse) boost::spirit::qi::rule<Iter, std::vector<std::string>(), boost::spirit::qi::locals<int, std::string>> service_search_list; service_search_list %= // %= operator is necessary for attribute propagation when using symantic attributes (anything in [ ]) string ("*ARSS") >> colon >> // Initial response +digit [qi::_a = qi::_1] >> crlf >> // Number of discovered devices - save in local qi::_a qi::omit [ok [qi::_b = qi::_1]] >> // Match but don't emit the "OK" here - save it for the end qi::repeat (qi::_a) // Repeat for each discovered device [ crlf >> ( qi::hold [profile1] | qi::hold [profile2] ... ) ] >> qi::attr(qi::_b); // Emit the "OK" here at the end of the list Using qi::int_[qi::_a = qi::_1] provides and empty string "" in the result and not "0". If I omit the numeric input from the result... qi::omit [qi::int_[qi::_a = qi::_1]] the parse will succeed but number of items in the response list is lost in the final result (omitted as requested). Any suggestion is appreciated, I'm stumped.

2 2

Re: [Boost-users] Boost::Bind Problem
by Sergey Zhuravlev 21 Sep '13

21 Sep '13

Try use TestBind f(boost::bind(boost::type<TestBind::t_ProcessFunctionInt>(), (&Test::process), &t1, _1)); for ambiguity. Either ...boost::bind<TestBind::t_ProcessFunctionInt>..., but less portable.

1 0