- Boost-users - lists.boost.org

Stack over flow error in the Chrobak_Payne_drawing.hpp
by Nishchal Devnur 14 May '11

14 May '11

> Hi All, > > I am trying to use the Chrobak_Payne_straight_line_drawing function to get > a straight line drawing of a biconnected and maximally planar graph. But I > am getting a stackoverflow error in the the Chrobak_Payne_drawing.hpp file. > https://docs.google.com/leaf?id=0B4H5FyR7-PhTYTg1ZmFjNDctNmE1ZC00NzYyLWIwM2… is the link to the screenshot of the stacktrace. The accumulate_offset > in the hpp file is being recursively called and hence the stackoverflow. I > am not sure whats the cause of this error. > > Here is the piece of my code : > > embedding_storage_t embedding_storage2(num_vertices(tempGraph)); > embedding_t embedding2(embedding_storage2.begin(), > get(vertex_index,tempGraph)); > isplanar = boyer_myrvold_planarity_test(boyer_myrvold_params::graph = > tempGraph, > boyer_myrvold_params::embedding = > &embedding2[0] > ); > // Find a canonical ordering > typedef std::vector<graph_traits<Graph>::vertex_descriptor> > ordering_storage_t; > ordering_storage_t ordering; > > planar_canonical_ordering(tempGraph, embedding2, > std::back_inserter(ordering)); > ordering_storage_t::iterator oi; > for ( oi = ordering.begin();oi!=ordering.end();oi++) > cout<<*oi<<endl; > > //Set up a property map to hold the mapping from vertices to coord_t's > typedef std::vector< planar_coord > straight_line_drawing_storage_t; > typedef boost::iterator_property_map > <straight_line_drawing_storage_t::iterator,property_map<Graph, > vertex_index_t>::type> straight_line_drawing_t; > > straight_line_drawing_storage_t > straight_line_drawing_storage(num_vertices(tempGraph)); > straight_line_drawing_t > straight_line_drawing(straight_line_drawing_storage.begin(),get(vertex_index,tempGraph)); > > chrobak_payne_straight_line_drawing(tempGraph, > embedding2, > ordering.begin(), > ordering.end(), > straight_line_drawing > ); > > Also the same code works in some cases when the size of the graphs is > small, but as the size of the graph grows I am getting this stackoverflow > error. Could anyone kindly letme know why this error occurs and if there is > any other extra care I need to take care off ? > > Thanks, > Nishchal. > -- Nishchal Devanur

3 3

Error closing an asio::socket
by Claude 14 May '11

14 May '11

Hello. In a program server in c++ I create an asio::socket and I listen it on a port (myPortNumber). Then I connect to my program using telnet (linux) with: telnet localhost myPortNumber The communication works fine, except that when I close the terminal window, the server closes with an error message: "terminate called without an active exception Aborted Process returned 134 (0x86)" Why? How can I prevent the server program is interrupted? -- View this message in context: http://boost.2283326.n4.nabble.com/Error-closing-an-asio-socket-tp3521153p3… Sent from the Boost - Users mailing list archive at Nabble.com.

2 3

[asio] How socket::shutdown() safe is within multithreaded usage?
by Slav 14 May '11

14 May '11

Hello, my server runs single io_service and asynchronosly accepts incoming connections (creating new sockets for each incoming connection). Usage of connection happens in such ways: - calls to socket::async_write() from multiple threads (embraced to mutex) at any time - handling socket::acync_read() (which runs within io_service' thread as I understand the documentation) - single call to socket::shutdown() at any moment from some other thread Previusly I used multiple of mutexes to cleanly wait for all current asynchronous read/write handlers: write function incremented "writes" variable which then was used on socket shutdown to wait the same amount of write handlers - but deadlock sometimes happend at moment of waiting write handlers. So I referred to socket::shutdown()'s documentation which say "Any asynchronous send, receive or connect operations will be cancelled immediately" - and don't wait any asynchronous operations for now and everything seems to work fine for now (what scares me). Is it safe to do so? How must I safely handle all currenlty running asynchronous read/write handlers? In case of boost.asio waits for all asynchronous operations to stop inside socket::shutdown/close so, then, if to call it within one of such operations - deadlock will (theoretically must) happen - so, socket::close/shutdown isn't safe? Thank you.

1 0

Boost.Context review result
by Vicente BOTET 14 May '11

14 May '11

Hi, this was my first experience as review manager and it has been more difficult than I had expected. Apologies if I forget some important things or I misunderstood others. I hope that the major points have been taken in account. Here it is the result of the Boost.Context review. The library is accepted provisionally and will need to address some mandatory points before a mini review (4/5 days). There were not too much complete reviews (5) but globally all the reviewers voted for acceptation and two subject to some major redesign modifications. I hope I didn't miss somebody. YES Gordon Woodhull YES/Cnd Giovanni Piero Deretta YES Artyom YES Nat Linden YES Phil Endecott YES/Cnd, Jeffrey Lee Hellrung, Jr Thanks to all the review participants Gordon Woodhull, Giovanni Piero Deretta , Artyom, Nat Linden, Holger Grund, Phil Endecott, Jeffrey Lee Hellrung, Jr.. Special thanks to Giovanni Piero Deretta showing some major flaws in the global design and Holger Grund for showing a (possible) major bug on the Windows implementation. I know Oliver that you have already redesigned your library, but if there are points that you have not been addressed yet or have some difficulties addressing them, I will suggest you to work closely with Giovanni, he know well the domain and have a lot of good ideas, and exchange on this ML. You should follow up more closely the discussions during the mini review and even try to get feedback from the ML posting how you see your redesigned library. Point to be addressed before the mini review: Design 1. Separation of the context class in two interface: - A C-like interface that defines a POD struct that is memcpy-able and that can be implemented either using platform libraries, as ucontext, fibers or directly using assembler when a robust implementation is available. The context swap implementation don't need to save the signals as ucontext does. The following is just for illustrations purposes. struct boost_context; typedef void boost_context_fn_t(intptr_t); extern "C" void boost_context_make(boost_context* ctx, boost_context_fn_t * f, intptr_t p, ...); extern "C" void boost_context_swap(boost_context* from, boost_context const* to); extern "C" intptr_t boost_context_destroy( boost_context* fc); boost_context_make is a merge of get_context with make_context + some fields assignations. "A user will have lower expectations from such a low level API and at the same time will give more freedom for other people to implement on top of it higher abstractions as Boost.Corutines, Boost.Fibers ..." - A non-copiable but movable safe context class on top of the low level C-like interface, that will provide modern and efficient C++ interface, that is usable by a user in a safe way. The safe context class would just be one of the client of the C-like interface, other library authors could either use the underlying C-like API directly or the class context depending on wether they need the speed or safety. * The context class will not be templated any more, and the use of type erasure will ensure that. * The constructor will accept any C++ callable, function pointers, functors, ... * At this high level interface, the function provided by the user could throw exceptions, and the library must wrap the user function and needs to store the exception raised and provide an interface to retrieve them. 2. The stack implementation must ensure that the stack is unwound before it is destroyed. A stack should only be safely deallocated if either has been completely unwound or if it doesn't own any resources. A basic stack without protection seems mandatory. For debug purposes it has been required to provide some stack usage functions that allow to know the max size used for example. Implementation 3. The assembler implementation on Windows must be disallowed if the ABI bug reported by Holger is confirmed. As far as Windows provides a fiber implementation that is as efficient as the assembler one, the assembler implementation is not mandatory and the user of the provided Windows fiber is a preferable choice. 4. Most of the 'throw' statements in the context class should actually be asserts. 5. The provided stack should be used to store any context parameters as far as no major impediment is found during the implementation. This will avoid further allocations on the safe context class. Documentation 6. The documentation is very minimalist and should be expanded with a discussion on context switching and use cases. Take care of all the grammar/spelling improvements suggested by the reviewers (It will be great if Jeffrey could review the documentation before the mini-review). Some user land examples should be provided (why not the yield example). 7. The concept of (Movable) Stack must be clearly defined, as it is done in the standard, using expression requirements with semantic constraints. 8. The assembler implementation should be carefully documented, so others could maintain the code and add other implementations if needed. 9. Some performance measure should be added. Providing the number of cycles on each implemented platform would be nice. Build system 10. The default build on a platform must work (It must be ABI compatible with the underlying platform) and take care of the specific features. Of course, the build needs to support cross compiling, so the user should be able to override the default values. Others points that are not required but that can make the library more usable or efficient: 1. The assembler implementations could be simplified if the context itself was represented as a single pointer to the top of the stack. This would save some instructions to move the source address from the stack return address to the context struct and back. 2. Instead of supporting a 'fc_link' a-la ucontext, have the callback function return a new context (it is void now). 'fc_link' is useful only on some limited cases (usually when you have an external scheduler managing your contexts), while the having the callback return the 'next continuation' has more applications (note that fc_link can be implemented easily in term of the continuation returning variant, but the reverse is harder). This will be very useful, for example, to implement some kind of 'exit_to' functionality (unwind the stack and restore another context), a key piece for safe context destruction. 3. Give to boost_context_swap the ability to exchange a parameter with the other context: boost_context_parm_t boost_context_swap( boost_context * ofc, boost_context const* nfc, boost_context_parm_t parm) where boost_context_parm_t is either union boost_context_parm_t { void * ptr; int int_; }; or simply intptr_t; boost_context_swap saves the current context in ocf and restores the context ncf as usual; additionally, if ofc was 'captured' on a call to boost_context_swap, this call will return the value of parm on the original context. This extra parameter is equivalent to the second parameter of longjmp. If ofc was created with boost_context_swap, 'parm' will be an extra parameter to the function. Note that this can be potentially implemented with little or no overhead. 4. Add a variant of boost_context_swap that allows executing a function on the destination context (in this case 'parm' would be passed parameter to this function. This is mostly useful for injecting an exception on the destination context. This can be potentially implemented on top of the existing functionality, but would slow down every context switch; a possible efficient implementation would manipulate the destination stack to add a call to the function on top of it, so that the cost is paid only when required. 5. Add a current context function (thread local). Vicente Review Manager

1 0

Serialization assert fail and unregistered class
by Jari 14 May '11

14 May '11

Hi i get assert fail and "unregistered class - derived class not registered or exported" when serializing. I have many classes being saved already in the code but i ran to a problem saving certain std::list with derived classes. (I also have similar classes and list being serialized before) i think its the same issue as in here: http://boost.2283326.n4.nabble.com/serialization-polymorphic-archives-runti… i have boost version 1.46.1 heres the call stack: > msvcr100d.dll!_wassert(const wchar_t * expr, const wchar_t * filename, unsigned int lineno) Line 325 C gamevc10dbg.exe!boost::archive::detail::basic_serializer_map::find(const boost::serialization::extended_type_info & eti) Line 102 + 0x16 bytes C++ gamevc10dbg.exe!boost::archive::detail::archive_serializer_map<boost::archive::binary_oarchive>::find(const boost::serialization::extended_type_info & eti) Line 67 C++ gamevc10dbg.exe!boost::archive::detail::save_pointer_type<boost::archive::binary_oarchive>::polymorphic::save<BasePlayer>(boost::archive::binary_oarchive & ar, BasePlayer & t) Line 435 + 0xe bytes C++ gamevc10dbg.exe!boost::archive::detail::save_pointer_type<boost::archive::binary_oarchive>::save<BasePlayer>(boost::archive::binary_oarchive & ar, const BasePlayer & t) Line 460 + 0xd bytes C++ gamevc10dbg.exe!boost::archive::detail::save_pointer_type<boost::archive::binary_oarchive>::invoke<BasePlayer *>(boost::archive::binary_oarchive & ar, BasePlayer * const t) Line 473 + 0xd bytes C++ gamevc10dbg.exe!boost::archive::save<boost::archive::binary_oarchive,BasePlayer * const>(boost::archive::binary_oarchive & ar, BasePlayer * const & t) Line 525 + 0xf bytes C++ gamevc10dbg.exe!boost::archive::detail::common_oarchive<boost::archive::binary_oarchive>::save_override<BasePlayer * const>(BasePlayer * const & t, int __formal) Line 69 + 0x15 bytes C++ gamevc10dbg.exe!boost::archive::basic_binary_oarchive<boost::archive::binary_oarchive>::save_override<BasePlayer *>(BasePlayer * const & t, int version) Line 76 C++ gamevc10dbg.exe!boost::archive::binary_oarchive_impl<boost::archive::binary_oarchive,char,std::char_traits<char> >::save_override<BasePlayer *>(BasePlayer * & t, int __formal) Line 52 C++ gamevc10dbg.exe!boost::archive::detail::interface_oarchive<boost::archive::binary_oarchive>::operator<<<BasePlayer *>(BasePlayer * & t) Line 64 C++ gamevc10dbg.exe!saveGame() Line 63 + 0x12 bytes C++ gamevc10dbg.exe!SDL_main(int argc, char * * argv) Line 1517 + 0x5 bytes C++ gamevc10dbg.exe!_main() + 0xfd bytes C gamevc10dbg.exe!_WinMain@16() + 0x1cd bytes C gamevc10dbg.exe!__tmainCRTStartup() Line 547 + 0x2c bytes C gamevc10dbg.exe!WinMainCRTStartup() Line 371 C kernel32.dll!75451194() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] ntdll.dll!76fbb429() ntdll.dll!76fbb3fc() gamevc10dbg.exe!__CT??_R0?AVbad_cast@std@@@8??0bad_cast@std@@QAE@ABV01@@Z12() + 0xd2ce bytes C++ 003426e2() does any one know whats wrong? i should have all BOOST_CLASS_EXPORT_GUID in place. thx

1 0

[GIL] Supporting filesystem::path
by Szymon Gatner 13 May '11

13 May '11

Hi, small feature request: adding support for filesystem::path class in new GIL.IO in calls like read_image(). P.S. Regarding my earlier request: any plans on adding file path to the exception thrown from read_image()? Cheers, Simon

2 1

building boost in AIX machine
by Manoj Jangid 13 May '11

13 May '11

Is boost library fully compatible with AIX machine? I am trying to build boost in AIX (5.3 and 6) machine and its stuck somewhere -------------------- ....... ....... ::pthread_mutex,32,0> > > &, nil_t, const lex_iterator<boost::wave::cpplexer::le x_token<boost::wave::util::file_position<boost::wave::util::flex_string<char,std ::char_traits<char>,std::allocator<char>,boost::wave::util::CowString<boost::wav e::util::AllocatorStringStorage<char,std::allocator<char> >,char *> > > > > &, c onst lex_iterator<boost::wave::cpplexer::lex_token<boost::wave::util::file_posit ion<boost::wave::util::flex_string<char,std::char_traits<char>,std::allocator<ch ar>,boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >,char *> > > > > &) could not be inlined into boost::spiri t::classic::action_policy::do_action<boost::wave::grammars::impl::store_found_eo ltokens<std::list<boost::wave::cpplexer::lex_token<boost::wave::util::file_posit ion<boost::wave::util::flex_string<char,std::char_traits<char>,std::allocator<ch ar>,boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage<char, std::allocator<char> >,char *> > > >,boost::fast_pool_allocator<boost::wave::cpp lexer::lex_token<boost::wave::util::file_position<boost::wave::util::flex_string <char,std::char_traits<char>,std::allocator<char>,boost::wave::util::CowString<b oost::wave::util::AllocatorStringStorage<char,std::allocator<char> >,char *> > > >,boost::default_user_allocator_new_delete,boost::details::pool::pthread_mutex, 32,0> > >,boost::spirit::classic::nil_t,boost::wave::cpplexer::lex_iterator<boos t::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::util: :flex_string<char,std::char_traits<char>,std::allocator<char>,boost::wave::util: :CowString<boost::wave::util::AllocatorStringStorage<char,std::allocator<char> > ,char *> > > > > >(const store_found_eoltokens<std::list<boost::wave::cpplexer:: lex_token<boost::wave::util::file_position<boost::wave::util::flex_string<char,s td::char_traits<char>,std::allocator<char>,boost::wave::util::CowString<boost::w ave::util::AllocatorStringStorage<char,std::allocator<char> >,char *> > > >,boos t::fast_pool_allocator<boost::wave::cpplexer::lex_token<boost::wave::util::file_ position<boost::wave::util::flex_string<char,std::char_traits<char>,std::allocat or<char>,boost::wave::util::CowString<boost::wave::util::AllocatorStringStorage< char,std::allocator<char> >,char *> > > >,boost::default_user_allocator_new_dele te,boost::details::pool::pthread_mutex,32,0> > > &, nil_t &, const lex_iterator< boost::wave::cpplexer::lex_token<boost::wave::util::file_position<boost::wave::u til::flex_string<char,std::char_traits<char>,std::allocator<char>,boost::wave::u til::CowString<boost::wave::util::AllocatorStringStorage<char,std::allocator<cha r> >,char *> > > > > &, const lex_iterator<boost::wave::cpplexer::lex_token<boos t::wave::util::file_position<boost::wave::util::flex_string<char,std::char_trait s<char>,std::allocator<char>,boost::wave::util::CowString<boost::wave::util::All ocatorStringStorage<char,std::allocator<char> >,char *> > > > > &) const. ----------------------------------------------- can you please tell me is there any other way to build?

1 0

boost::get_error_info not found!?
by Germán Diago 13 May '11

13 May '11

Hello. I have this code and I can't find out why it won't compile. I have looked at it several times and I can't find the reason. My definitions: enum ErrorCode { Success, BadOptions = -1, CannotConnect = -3 }; class ConsoleException : virtual public boost::exception, virtual public std::exception {}; namespace ExceptionTags { struct ErrorCodeTag {}; } My throw: BOOST_THROW_EXCEPTION(CabConsoleException() << ErrorCodeInfo(BadOptions)); And in main: try { CabConsole2 console; console.run(argc, argv); } catch (boost::exception & ce) { return 0; return *(boost::get_error_info<ExceptionTags::ErrorCodeTag>(ce)); } I'm using boost version 1.42. Thanks in advance.

2 3

[Interprocess] updating elements in vector of maps fails in optimized code
by Steven Maenhout 13 May '11

13 May '11

I'm using Boost 1.46 on Linux x86_64 in combination with gcc version 4.5.1. I'm trying to implement a a sparse matrix in a shared memory segment as a vector of maps. When trying to update previously inserted elements of the matrix, at a certain point, the program either crashes or stalls indefinitely. This only occurs if the gcc optimization is set higher than O0. If compiler optimizations are completely turned off (so using the -O0 switch) the program works as expected. Below, I provide some trimmed code that demonstrates the problem. I would be very grateful if somebody could indicate me what's causing this erratic behavior. Steven #include <iostream> #include <stdexcept> #include <boost/interprocess/managed_shared_memory.hpp> #include <boost/interprocess/containers/map.hpp> #include <boost/interprocess/containers/vector.hpp> #include <boost/interprocess/allocators/allocator.hpp> #define MATSIZE 5 typedef boost::interprocess::managed_shared_memory::segment_manager SegmentManager_t; typedef boost::interprocess::allocator<void , SegmentManager_t> VoidAllocator_t; typedef std::pair<int,double> MapValue_t; typedef boost::interprocess::allocator<MapValue_t , SegmentManager_t> MapValueAllocator_t; typedef boost::interprocess::map<int,double,std::less<int>,MapValueAllocator_t> Map_t; typedef boost::interprocess::allocator<Map_t,SegmentManager_t> MapAllocator_t; typedef boost::interprocess::vector<Map_t,MapAllocator_t> VectorofMaps_t; int main(int argc, char **argv) { VectorofMaps_t::size_type i; int j; Map_t::iterator mapiter; try { boost::interprocess::shared_memory_object::remove("MySharedMemory"); boost::interprocess::managed_shared_memory mfile(boost::interprocess::create_only,"MySharedMemory",65536); VoidAllocator_t alloc_inst (mfile.get_segment_manager()); VectorofMaps_t* pS=mfile.construct<VectorofMaps_t>(boost::interprocess::anonymous_instance)(MATSIZE,Map_t(std::less<int>(),alloc_inst),alloc_inst); for(i=0;i<MATSIZE;++i) { for(j=0;j<MATSIZE;++j) (*pS)[i].insert(std::pair<int,double>(j,1.0)); } for(i=0;i<MATSIZE;++i) { for(j=0;j<MATSIZE;++j) { mapiter=(*pS)[i].find(j); if(mapiter!=(*pS)[i].end()) mapiter->second+=1.0; else (*pS)[i].insert(std::pair<int,double>(j,1.0)); } } for(i=0;i<MATSIZE;++i) { for(mapiter=(*pS)[i].begin();mapiter!=(*pS)[i].end();++mapiter) std::cout<<mapiter->second<<" "; std::cout<<std::endl; } boost::interprocess::shared_memory_object::remove("MySharedMemory"); } catch(boost::interprocess::interprocess_exception e) { std::cerr<<"Interprocess error: "<<e.what(); } catch(std::exception e) { std::cerr<<"Standard exception: "<<e.what(); } catch(...) { std::cerr<<"unknown error"; } }

3 7

[BGL] Using copy_graph(g_in, g_out) with filtered_graph (and a special predicate) as input yields an unexpectedly empty graph
by Cedric Laczny 13 May '11

13 May '11

Hi, in order to select a subgraph based on some predicates, I use filtered_graph() with an appropriate predicate. To get the resulting subgraph (strictly speaking it is a new graph), I simply use copy_graph(fg, new_g). In a special situation, this predicate simply filters on the name and type of a vertex (set via vertex_properties). This is working as expected. The more, I am working with multipartite graphs, so there are no edges between 2 vertices of the same type. When I now define a predicate that will only let vertices of one special type to be visible and I use copy_graph() on this filtered_graph, the resulting graph has no edges (which is ok) but it also has no vertices. I would not expect the latter to happen. In turn, when I let another type of vertices to be visible, the resulting graph is again as expected. Is there perhaps some obvious speciality of copy_graph() I am missing? Best, Cedric

2 2