- Boost - lists.boost.org

Re: [boost] Review of a safer memory management approach for C++
by Bartlett, Roscoe A 08 Jun '10

08 Jun '10

Mathias, > ------------------------------ > > Message: 19 > Date: Mon, 07 Jun 2010 15:43:18 +0100 > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: <huj0io$6iu$1(a)dough.gmane.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Bartlett, Roscoe A wrote: > > > I am fine with the language allowing for undefined behavior. Clearly > if you want the highest performance, you have to turn off array-bounds > checking, for instance, which allows for undefined behavior. What I > am not okay with is people writing programs that expose that undefined > behavior, especially w.r.t. to usage of memory. Every computational > scientist has had the experience of writing code that appeared to work > just fine on their main development platform but when they took to over > to another machine for a "production" run on a large (expensive) MPP to > run on 1000 processors, it segfaulted after having run for 45 minutes > and lost everything. This happens all the time with current CSE > software written in C, C++, and even Fortran. This is bad on many > levels. > > > > Are you suggesting that people should write programs that rely on > undefined behavior or are you just saying that you don't think it > should be eliminated from the language? > > From my experience, the best tool to identify and eliminate undefined > behaviour due to bad memory access is valgrind. > > I found it more practical and catching more errors than any > library-level tool. [Bartlett, Roscoe A] Tools like valgrind and purify are very helpful but are not nearly sufficient as described in Section 3.2 (and other sections) in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf Have other people had similar experiences with valgrind and purify to what I describe in Sectioin 3.2 in the above document? If valgrind and purify can pin-point memory errors so effectively, then why does it sometimes take nearly a week to track down certain types of memory errors in C++ (I have heard of such stories)? My record is most likely about three days to track down a single memory error (including using valgrind and purify for all the glues that I can get, less they segfaulted themselves of course which sometimes they do). In the process of tracking down and diagnosing some of these memory errors, I have had to apply all of my PhD-level problem solving and research skills and in the end I could not write a research paper to describe the wonderful problem-solving research-quality work that I did. What a waste of time and effort; very frustrating. I know many people that I work with that have had similar experiences. These types of experiences have lead many C++ teams to code C++ with a (justified but unfortunate) paranoia about the use of memory in C++ that has all kinds of bad consequences (see Section 1 in the above document for some of the consequences). Come one, at least some people on this mail list must have had similar nightmare experiences in trying to track down and diagnose hard memory misuse errors in C++ that took days of effort to resolve (even with the help of tools like valgrind and purify). And again, tools like valgrind and purify will *never* catch semantic misuse of memory (i.e. allocating a big chunk of memory and then breaking it up to be used to construct different objects and array of objects). The Teuchos MM classes will catch most semantic misuse of memory in a way that no tool like valgrind and purify every can (because they don't know the context of your program, they only know that any read/writes in a big block of memory that you allocated look okay). I think this is a big deal in catching hard-to-find defects that are not (technically speaking) memory misuse defects but are program defects none the less. Cheers, - Ross

6 9

[msm] Nested submachines and explicit state entry
by Michael.Herchel＠rohde-schwarz.com 08 Jun '10

08 Jun '10

Hi, As already stated in the documentation it is possible to have explicit state entry into another submachine within a state machine. Is there a possibility to have a state machine, which has another submachine with explicit state entry and that submachine has another submachine with an initial transition. I put that together in a picture and attached it. I hope then it gets clearer what I want to do. The picture shows just a simplified version of the overall state machine and I discarded some other states, transitions and orthogonal regions. How do I have to declare the transition table and states in that case? Are there any restrictions regarding nested depth? Best Regards, Michael

1 0

boost::thread compiler error on SUN CC 5.9
by Urs Stotz 08 Jun '10

08 Jun '10

boost::thread give a compile error on SUN CC 5.9: /opt/SUNWspro/bin/CC +d -library=stlport4 -library=stlport4 -xcode=pic32 -erroff=wvarhidemem,hidevf,hidevfinvb -errtags=yes -features=tmplife -features=tmplrefstatic -g -mt -erroff=%none -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -I"." -c -o "bin.v2/libs/thread/build/sun-5.9/debug/stdlib-sun-stlport/threading-multi/pthread/thread.o" "libs/thread/src/pthread/thread.cpp" "libs/thread/src/pthread/thread.cpp", line 77: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> && void*" is illegal. "libs/thread/src/pthread/thread.cpp", line 588: Error, badbinaryop: The operation "boost::shared_ptr<boost::detail::tss_cleanup_function> || void*" is illegal. 2 Error(s) detected. make: *** [thread.o] Error 2 with this small patch it will compile: --- boost_1_42_0.org/libs/thread/src/pthread/thread.cpp 2009-10-19 11:18:13.000000000 +0200 +++ boost_1_42_0/libs/thread/src/pthread/thread.cpp 2010-02-10 13:48:25.037748000 +0100 @@ -74,7 +74,7 @@ namespace boost { current=next; ++next; - if(current->second.func && current->second.value) + if(current->second.func && (current->second.value != 0)) { (*current->second.func)(current->second.value); } @@ -585,7 +585,7 @@ namespace boost { (*current_node->func)(current_node->value); } - if(func || tss_data) + if(func || (tss_data != 0) ) { current_node->func=func; current_node->value=tss_data;

3 2

SPAM in trac
by Steven Watanabe 08 Jun '10

08 Jun '10

AMDG I just saw some spam here: https://svn.boost.org/trac/boost/ticket/1338 In Christ, Steven Watanabe

3 3

asio loopback behavior, windows vs. linux
by Adam Crain 08 Jun '10

08 Jun '10

There’s an interesting behavioral difference between how the loopback works with ASIO on windows/linux. I have constructed a test that talks to an echo server across the loopback. The test steps are: 1) Open the socket using run_one(), verifying it is open 2) Start an async read 3) Start an async write 4) Call run_one, then verify the write succeeds 5) Call run_one, then verify that the data you write is received 6) Goto step 2 some number of times since the behavior is non-determinsitic One windows, this seems to consistently fail within the first 100 iterations, because on occasional you get the read callback with echoed data before the write success comes back!!!! This seems crazy that another process answers you before the OS/ASIO has even told you the write was successful. On Linux I have not been able to make this happen even with 10K’s of iterations. I can only assume that: 1) This can actually happen with Windows loopback + thread scheduling and my assumption that write callbacks will always occur before response data is invalid 2) There is a bug in the windows impl of ASIO that makes this possible. If anyone can shed some light on this I’d really appreciate it. I have code that wants to step through a series of states, and it makes things a lot more complicated if I can’t assume that the write callback will always occur before data received that’s a response to what I sent. Thanks! Adam Adam Crain Manager of R&D Green Energy Corp. 919-428-1002

2 1

Re: [boost] [bjam][msm] help building tests
by Christophe Henry 07 Jun '10

07 Jun '10

>> I am almost ready for release, except that I run into a (admittedly >> expected) little snag. I have in the trunk a libs/msm/test. I also >> have a jamfile, which even compiles. But doesn't link. >> The reason being that bjam does not find the Boost.Test libs. Ok I >> understand I should be telling bjam to do it, but looking at other >> libraries' jamfiles, I don't find it either, so I'm wondering how this >> is supposed to work. Am I missing something? > > You can change libs/msm/test/Jamfile.v2 like this > > project msm > : > requirements > <include>. > <library>/boost/test//boost_unit_test_framework/<link>static > ; > > to link against Boost.Test libraries. I'm not sure but I think that's > all you need. > >> On a related note, I'm also wondering how to get the tests to show up >> on the trunk regression page. > > Look in status/Jamfile.v2 and follow the pattern (add line for msm/ > test in the appropriate place) to get your product's tests running. > > Hope that helps. > > -- Noel Hi Steven, Noel, Jürgen, Vicente, This is what I call getting good help fast! :) Thanks to all, I just did the changes and committed. Tests ran successfully (well, one 1 compiler...) and status/Jamfile.v2 now contains msm, so I eagerly wait for the results ;-) So I now go further through the check-list. From what I saw, the inspection report now considers msm as one of the worst offenders. Can't have that. ^^ Big big thanks to all! Christophe

1 0

[bjam][msm] help building tests
by Christophe Henry 07 Jun '10

07 Jun '10

Hi, I am almost ready for release, except that I run into a (admittedly expected) little snag. I have in the trunk a libs/msm/test. I also have a jamfile, which even compiles. But doesn't link. The reason being that bjam does not find the Boost.Test libs. Ok I understand I should be telling bjam to do it, but looking at other libraries' jamfiles, I don't find it either, so I'm wondering how this is supposed to work. Am I missing something? On a related note, I'm also wondering how to get the tests to show up on the trunk regression page. Thanks, Christophe

5 4

Re: [boost] [regex, xpressive] interesting(?) perf benchmark
by Christophe Henry 07 Jun '10

07 Jun '10

>> How about a warning "you may not be using the optimal tool for the job" >> until then? > > I'm having a hard time getting excited about that. :) >> Are the finite state machine libraries in Boost usable for this at all? > > I don't know. At BoostCon, Christophe presented some interesting results > pitting MSM against xpressive for some simple regexing. An interesting > research project would be to investigate whether xpressive's hybrid > static/dynamic NFA design can be applied to DFAs as well, with similar > perf wins. This would be a non-trivial undertaking, like completely > reimplementing xpressive. I think MSM could be a possibility, and it seems to be quite fast for some cases. I was actually thinking of handling static Xpressive as a MSM-compatible front-end, so that the user could switch at will between Xpressive and MSM, which happen to be complementary because most performant on different types of regexes. But there is a long way (and a fair number of technical issues) between a toy example and a real library so it could take a while before I get to it (besides, I am not a domain expert). Note: there is an example provided with the BoostCon slides. I have more and I can pack them with MSM's examples. Christophe

1 0

identifying file system type
by Roger Martin 07 Jun '10

07 Jun '10

Hi, I'm looking for a way code can automatically decide whether it is running on a parallel or non-parallel file system. Need to retrieve the information about the file system type. Get values like "ext3", "nfs" "gpfs", "pvfs", "Lustre" etc. Is there any file system info obtainable in code?

1 0

[trac] "Building Boost" vs. "build"
by Vladimir Prus 07 Jun '10

07 Jun '10

It looks like somebody went via Trac and moved some issues from the "Building Boost" component to "build" component. See, for example: https://svn.boost.org/trac/boost/ticket/4147 I certainly appreciate help with triaging issues, but in general, such change seems wrong -- "Building Boost" is for issues affecting exactly that -- building boost, while the 'build' component contain issues that are not necessary affecting Boost C++ Libraries at all. Unfortunately, the changes are all anonymous, so it would be great if whoever made them speak up, and discuss the rationale. Thanks, -- Vladimir Prus CodeSourcery vladimir(a)codesourcery.com (650) 331-3385 x722

4 5