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

[regex] segfault from construction
by Andrew Troschinetz 22 Nov '08

22 Nov '08

Hello all, I've got what I suspect is a relatively unique problem that's resulting in a segfault whenever I try to construct a boost::regex. First some machine information: Red Hat Enterprise Linux Server release 5.1 (Tikanga) Linux 2.6.18-53.el5, SMP, x86_64 gcc 4.1.2 20070626 (Red Hat 4.1.2-14) boost 1.33.1-10 Here's a small example that shows the problem: #include <boost/algorithm/string/regex.hpp> #include <iostream> #include <string> using namespace std; int main() { string input ("test test1 test2 test3"); string pattern ("\\btest\\b"); erase_regex (input, boost::regex (pattern)); cout << input << endl; // expecting " test1 test2 test3" return 0; } Compile flags (and this is getting to the heart of the problem, I think): -g -m32 -malign-double -O3 -Wall -lboost_regex Put all the above together in a bag, shake it up, and you get this segfault: 0x08066beb in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse_extended (this=0xffde311c) at /usr/include/boost/regex/v4/basic_regex_parser.hpp:235 235 switch*this->m_traits.syntax_type(*m_position)) (gdb) print m_position $1 = 0x0 (gdb) bt #0 0x08066beb in boost::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse_extended at /usr/include/boost/regex/v4/basic_regex_parser.hpp:235 #1 0xf7f9e364 in boost ::re_detail::basic_regex_parser<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse () from /usr/lib/libboost_regex.so.2 #2 0xf7fa0eba in boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign () from /usr/lib/ libboost_regex.so.2 #3 0x08050789 in main () at /usr/include/boost/regex/v4/ basic_regex.hpp:254 So the immediate culprit is a dereferencing-null problem. Interestingly, the problem goes away at -O, -O1, and -O2. Or -O3 but without -malign-double. I was wondering if this is a known problem, and if anyone else who's hand is forced to compile with -malign-double has seen this problem and been able to work around it? -- Andrew Troschinetz Applied Research Laboratories

4 4

Boost.Test with a static library
by Moritz Beber 22 Nov '08

22 Nov '08

Hello everyone, after prying for any hints in the documentation and reading frustrating mails in the archives for a while now, I get the feeling that this is a very confusing topic. My aim is to use a static library of boost.test because I need to compile it a lot and the waiting time when using the header is just frustrating. So I added to the "Jamfile.v2" in "libs/test/build" under "requirements" the following line: <define>BOOST_TEST_ALTERNATIVE_INIT_API=1 Then I used boost.build and apart from a few warnings like: ./boost/test/detail/config.hpp:85:1: warning: "BOOST_TEST_ALTERNATIVE_INIT_API" redefined <command-line>: warning: this is the location of the previous definition everything seemed alright. So I'm assuming I now have a static library with this macro defined so it should use the alternative initialiser. Then I tried the following code, which I mostly copied from the documentation, except for adding two macros: #define BOOST_TEST_NO_LIB #define BOOST_TEST_ALTERNATIVE_INIT_API #define BOOST_TEST_MODULE example #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_SUITE( test_suite1 ) BOOST_AUTO_TEST_CASE( test_case1 ) { BOOST_WARN( sizeof(int) < 4 ); } BOOST_AUTO_TEST_CASE( test_case2 ) { BOOST_REQUIRE_EQUAL( 1, 2 ); BOOST_FAIL( "Should never reach this line" ); } BOOST_AUTO_TEST_SUITE_END() BOOST_AUTO_TEST_SUITE( test_suite2 ) BOOST_AUTO_TEST_CASE( test_case3 ) { BOOST_CHECK( true ); } BOOST_AUTO_TEST_CASE( test_case4 ) { BOOST_CHECK( false ); } BOOST_AUTO_TEST_SUITE_END() When I try to compile, however, I get the following error: /home/engineer/libs/boost/lib/libboost_unit_test_framework-gcc43-mt-1_37.a(unit_test_main.o): In function `main': unit_test_main.cpp:(.text+0x2229): undefined reference to `init_unit_test()' collect2: ld returned 1 exit status Which I thought the macro BOOST_TEST_MODULE would take care of. I also tried using the BOOST_TEST_MAIN and took out the BOOST_TEST_NO_LIB. Nothing made a change to the compiler error. Can anyone help? Or give me a link to some proper documentation of how to resolve this issue? Thanks, Moritz

3 5

Boost.Statechart and Simulink
by Derek Ditch 22 Nov '08

22 Nov '08

I was wondering if there were any known issues with compiling using Matlab's mex compiler (which in turn uses and links with gcc) and using Boost.Statechart. When I implemented my statechart, I tested it using a separate main() file and it works 100%. When I compile using mex into a Matlab MEX file, I seem to lose the functionality of the event triggers. I've tried several things to figure out what is happening, but all I can ascertain is that if I use the iterators state_begin() and state_end() to access all internal states, the loop never executes. I tried to dereference state_begin(), but got a segfault. My initial approach was to use the state_downcast<>(), but this didn't work in SImulink either. My final suspicion was that it had something to do with the extern "C" business, but admittedly, I don't understand the effects of this statement other than how the symbol appears in the library (i.e. avoiding mangling). I get this same behavior on OS X 10.5 w/ gcc 4.0.1 as well as on Linux x86_64 with gcc 4.2.4. If anyone wants to have my Simulink model to test, I could send that as well. I've attached the following files: ctrl_machine.[ch]pp - My state machine implementation/declaration. main.cpp - My test program air_controller.cpp - The C++ SFunction implementation used in Simulink. mex uses the following compilation steps with gcc/g++ -> g++-4.2 -c -I/opt/matlab/extern/include -I/opt/matlab/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fPIC -fno-omit-frame-pointer -pthread -DMX_COMPAT_32 -O -DNDEBUG "ctrl_machine.cpp" -> g++-4.2 -c -I/opt/matlab/extern/include -I/opt/matlab/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fPIC -fno-omit-frame-pointer -pthread -DMX_COMPAT_32 -O -DNDEBUG "air_controller.cpp" -> gcc-4.2 -c -I/opt/matlab/extern/include -I/opt/matlab/simulink/include -DMATLAB_MEX_FILE -ansi -D_GNU_SOURCE -fexceptions -fPIC -fno-omit-frame-pointer -pthread -DMX_COMPAT_32 -O -DNDEBUG "/opt/matlab/extern/src/mexversion.c" -> g++-4.2 -O -pthread -shared -Wl,--version-script,/opt/matlab/extern/lib/glnxa64/mexFunction.map -Wl,--no-undefined -o "ctrl_machine.mexa64" ctrl_machine.o air_controller.o mexversion.o -Wl,-rpath-link,/opt/matlab/bin/glnxa64 -L/opt/matlab/bin/glnxa64 -lmx -lmex -lmat -lm -lm ----- Thanks, Derek Ditch

2 2

Re: [Boost-users] boost test with assert()
by Hicham Mouline 21 Nov '08

21 Nov '08

Hello, Any ideas re this issue? Can the assert from <cassert> be caught somehow? Regards,

3 6

std::vector and default constructor
by peter_foelsche＠agilent.com 21 Nov '08

21 Nov '08

It would be helpful to have something like std::vector which allows one to pass some argument which is in turn passed to the constructor of every element so that not the default constructor is being called. This would be helpful for e.g. objects located in memory created by memory mapped files. Peter "The first point (using an init() function in preference to a constructor) is bogus. Using constructors and exception handling is a more general and systematic way of dealing with resource acquisition and initialization errors. This style is a relic of pre-exception C++." -- Stroustrup

2 3

[test] new g++ compilation warnings on trunk
by Robert Mecklenburg 21 Nov '08

21 Nov '08

Compiling against the boost trunk I'm getting hundreds of these: g++ -Wall -Wextra -Wno-missing-braces -g -ftrapv -DBOOST_1_36_0 -Iboost-1_37 -MMD -MP -DUSE_TRAPV -c -o src/test/BlobTest.o src/test/BlobTest.cpp boost/test/floating_point_comparison.hpp:224: warning: 'boost::test_tools::<unnamed>::check_is_close' defined but not used boost/test/floating_point_comparison.hpp:246: warning: 'boost::test_tools::<unnamed>::check_is_small' defined but not used Any chance we can fix this? If you need a tester for g++ 4.2.3, I can do it. Thanks, -- Robert

5 5

[Test] Compilation problem
by Greg Ravikovich 21 Nov '08

21 Nov '08

Hello, I'm using boost 1.37 and have the following problem: A blank cpp file containing only: #include <boost/test/test_case_template.hpp> fails to compile on vc9. However a blank cpp containing: #include <boost/test/unit_test.hpp> #include <boost/test/test_case_template.hpp> compiles fine. A file containing #include <boost/test/test_case_template.hpp> #include <boost/test/unit_test.hpp> won't compile as well. Is this intentional? Or is there a missing include directive inside test_case_template? Thanks, Greg

2 1

boost test with assert()
by Hicham Mouline 21 Nov '08

21 Nov '08

Hello, I use this test class: class SimulationIdTest { public: static void TestDestructorAfterAddRemoveSimulation(); static void TestDestructorAfterAddRemoveContractSimulation(); static void AddTests(boost::unit_test::test_suite* suite); }; TestDestructorxxx() are written so that the code inside, indirectly, throws an assert(false) (not my code) I would like to test that indeed, it does throw the assert(false). void SimulationIdTest::AddTests(boost::unit_test::test_suite* suite) { suite->add(BOOST_TEST_CASE(TestDestructorAfterAddRemoveSimulation), 1); } I tried the above by saying there would be 1 failure, however the test suite stops on that failure ( the assert(false) ), even the second argument of suite->add is 1. Is there a solution to this case? Regards,

2 1

tweaking the review process (was: signals2 review results)
by Stjepan Rajko 21 Nov '08

21 Nov '08

Hi Paul, On Fri, Nov 21, 2008 at 1:00 AM, Paul Baxter <pauljbaxter(a)hotmail.com> wrote: > On Thu, Nov 20, 2008 at 11:40 PM, vicente.botet <vicente.botet(a)wanadoo.fr> wrote: >> I would like to make some suggestion to improve the review management: > > <valid points snipped> > > Whilst I understand your points, unlike our day job, people do have other > more pressing commitments and, for many, the extensive effort given to > reviewing boost libraries is time given in an ad-hoc manner. > > Whilst it is good to have the timetable and a specific method for submitting > reviews, I don't think we need to go further and be more regimented. The > existing flexibility is a positive part of the process, IMHO. I also tend to prefer flexibility when people are volunteering their time. > > [ I do have problems with some libraries actually getting to the point of > review before interest, maturity of interface or implementation are right, > but that doesn't apply here and has been covered in previous discussions.] > I think I was guilty of this / have been bit by this myself. Anyway, there are two things that I think can help here: * requiring a certain number of committed reviewers before scheduling a review * the review manager being more active in examining the library before the actual review About the latter - in both reviews I managed, there was a number of issues (e.g., documentation shortfalls) that came up during the review that I, as review manager, could have discussed privately with the author beforehand had I done a more thorough review of the library. These issues could have been fixed before a review was scheduled, and the reviews could have been more focused on other issues. The review process page states: "The Review Manager... Checks the submission to make sure it really is complete enough to warrant formal review. See the Boost Library Requirements and Guidelines. If necessary, work with the submitter to verify the code compiles and runs correctly on several compilers and platforms." Well, in both cases I had examined the library, tried it on several compilers, read the docs, glanced at the implementation, etc. But it wasn't a thorough review. I think, had I actually gone through the reviewer's list of questions and wrote a full review, it would have given the authors some idea of possible areas that can be improved before the review (being careful not to react prematurely in possibly contentious areas where the opinion of just one person is not enough). Doing something like this would require additional effort from the review manager, but I think it would result in a much better review (and one where it is possibly easier to make a decision because there are fewer remaining problems). Best, Stjepan

2 2

error LNK2019: :assertion_failed wrt boost::detail::basic_timed_mutex::lock
by Joseph A. Marks 21 Nov '08

21 Nov '08

Hi! Could anyone please help me out with the following error? : error LNK2019: unresolved external symbol "void __cdecl boost::assertion_failed(char const *,char const *,char const *,long)" (?assertion_failed@boost@@YAXPBD00J@Z) referenced in function "public: void __thiscall boost::detail::basic_timed_mutex::lock(void)" (?lock@basic_timed_mutex@detail@boost@@QAEXXZ) Thanks in Advance! Joseph A. Marks PHONE: 612-788-9658 e-mail: josephamarks(a)yahoo.com

1 0