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

serialization 1.36.0 extended_type_info exit issue(s)
by Tim St. Clair 13 Oct '08

13 Oct '08

Folks, I'm running some serialization unit-tests which pass with flying colors under 1.35.0 and earlier, however they seg-fault on exit when run through 1.36.0. The error appears to deal with destruction of extended_type_info_typeid objects, and *only* manifests itself when I load an archive through a shared_ptr<T>. The load will appear to function properly, then on exit of the application, <<Death>>. This occurs even if I remove BOOST_CLASS_EXPORT && BOOST_CLASS_TYPE_INFO as the shared_ptr is to the derived element, and I'm not testing through a base. My lastest guess is that I may be missing some #define BOOST_SOME_MAGIC_NEW_OPTION //////////////////////////// pseduo code: //////////////////////////// BOOST_AUTO_TEST_CASE( MyTestClass_Serialization ) { boost::shared_ptr<MyTestClass> outtie ( new MyTestClass() ); boost::shared_ptr<MyTestClass> innie; std::ofstream os( "MyTestClass_Serialization.xml", std::ios_base::out ); my_pack< MyTestClass >( os, outtie ); os.close(); std::ifstream is( "MyTestClass_Serialization.xml", std::ios_base::in ); my_unpack< MyTestClass >( is, innie ); is.close(); BOOST_CHECK_NO_THROW(); } //////////////////////////// ddd output: //////////////////////////// *** No errors detected [New Thread 0xb73e26c0 (LWP 4715)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb73e26c0 (LWP 4715)] 0xb76bb56b in std::_Rb_tree_rebalance_for_erase () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0xb76bb56b in std::_Rb_tree_rebalance_for_erase () from /usr/lib/libstdc++.so.6 #1 0xb7a38221 in std::_Rb_tree<boost::serialization::detail::extended_type_info_typeid_0 const*, boost::serialization::detail::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::detail::extended_type_info_typeid_0 const*>, boost::serialization::detail::type_compare, std::allocator<boost::serialization::detail::extended_type_info_typeid_0 const*> >::erase (this=0xb7a93c94, __position={_M_node = 0x810a3f8}) at /usr/include/c++/4.2/bits/stl_tree.h:1261 #2 0xb7a38270 in std::multiset<boost::serialization::detail::extended_type_info_typeid_0 const*, boost::serialization::detail::type_compare, std::allocator<boost::serialization::detail::extended_type_info_typeid_0 const*> >::erase (this=0xb7a93c94, __position={_M_node = 0x810a3f8}) at /usr/include/c++/4.2/bits/stl_multiset.h:346 #3 0xb7a37482 in boost::serialization::detail::extended_type_info_typeid_0::type_unregister (this=0x810749c) at /opt/tomodev/env/boost/libs/serialization/src/extended_type_info_typeid.cpp:93 #4 0x080b001a in ~extended_type_info_typeid (this=0x810749c) at /opt/tomodev/env/boost/boost/serialization/extended_type_info_typeid.hpp:80 #5 0x0809ebe2 in __tcf_49 () at /opt/tomodev/env/boost/boost/serialization/singleton.hpp:104 #6 0xb74f7084 in exit () from /lib/tls/i686/cmov/libc.so.6 #7 0xb74df458 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6 #8 0x0809e691 in _start () Cheers, Timothy St. Clair [timothysc(a)gmail.com]

9 37

Linker error with boost_1_36_0
by kumar bhargav 13 Oct '08

13 Oct '08

Hi, I built the thread library after downloading "boost_1_36_0.zip". After building the thread library from bjam, when I build the program in VS2008, I get following linker error:- Error 1 fatal error LNK1104: cannot open file 'libboost_thread-vc90-mt-gd-1_36.lib' What I see in the generated library folder is that boost_thread-vc90-mt-gd-1_36.lib is generated, but the linker is looking for 'libboost_thread-vc90-mt-gd-1_36.lib'. I have already done the required changes in the project properties mentioned at http://www.boost.org/doc/libs/1_36_0/more/getting_started/windows.html . Similar thing happening with Regex library also. The generated lib is boost_regex-vc90-gd-1_36.lib, but the linker is looking for libboost_regex-vc90-gd-1_36.lib. Is there any other settings change required or something else? Thanks, Bhargav.

5 9

[Function] Encapsulated inside a class, won't initialize.
by Ravey Alexandre 13 Oct '08

13 Oct '08

Hi there, I'm using boost::function defined private inside a class and then assign a function comming from another boost::function. But it don't work. A little code may help understand my pretty bad explanation. ####### class C { public: void Bind(boost::function<void()> f); private: boost::function<void()> func; }; void C::Bind(boost::function<void()> f) { func = f; //Compile, but raise an access violation. } ####### The problem seems obvious to me, func si not initialized correctly and swap() fail. But I can't figure out how to make this work. Thanks for your help.

2 1

Visual C++ 2003 and Boost 1.35
by Tomek Jerzykowski 13 Oct '08

13 Oct '08

Hello! I'm having a problem with using Boost 1.35 on Visual C++ 2003 SP1. Take a look at the following very simple program: ------------------------------------ #include "stdafx.h" #include <boost/interprocess/sync/interprocess_upgradable_mutex.hpp> int _tmain(int argc, _TCHAR* argv[]) { int i = 0; unsigned int j = 2; j < i; return 0; } ------------------------------------ It does nothing, just emits a compiler warning. Unfortunately, this warning is followed by lots of meaningless messages related to the included Boost header: ------------------------------------ BoostTest2.cpp c:\BoostTest2\BoostTest2.cpp(11) : warning C4018: '<' : signed/unsigned mismatch c:\Program Files\boost\boost_1_35_0\boost\interprocess\sync\interprocess_upgradable_mut ex.hpp(621) : see reference to class template instantiation 'boost::interprocess::upgradable_lock<M>' being compiled with [ M=boost::interprocess::interprocess_mutex ] c:\Program Files\boost\boost_1_35_0\boost\interprocess\sync\interprocess_upgradable_mut ex.hpp(621) : see reference to class template instantiation 'boost::interprocess::upgradable_lock<M>' being compiled with [ M=boost::interprocess::interprocess_mutex ] ------------------------------------ If I remove #include <boost..., the extra messages go away. It looks to me like compiler bug. The exe produced is probably ok, but the amount of spam in output window makes using Boost very cumbersome. Is there any way to make these messages go away?

6 9

boost::noncopyable doesn't work
by Maurer Philipp 13 Oct '08

13 Oct '08

Hello, I have a very special problem concerning boost::noncopyable under Windows in a shared library. A class deriving from boost::noncopyable becomes copyable. Strange ? Here is the example code. (Using Visual Studio 2005, no sp, Windows XP): 1) create one static lib with only TestClasses.hpp with the following content in it: #include <boost/noncopyable.hpp> class INonCopyNormalClass: boost::noncopyable { public: virtual INonCopyNormalClass* clone() = 0; }; 2) create one DLL (shared lib) with the following content: DLLMain.hpp: #include "../TestLib/TestClasses.hpp" # if defined(UNCOPYABLETESTDLL_EXPORTS) # define DLL_API __declspec(dllexport) # else # define DLL_API # endif class DLL_API AnotherNonNormalCopyClass: public INonCopyNormalClass { }; class YetAnotherNonNormalCopyClass: public AnotherNonNormalCopyClass { public: YetAnotherNonNormalCopyClass(); virtual INonCopyNormalClass* clone(); }; DLLMain.cpp: #include "DLLmain.hpp" YetAnotherNonNormalCopyClass::YetAnotherNonNormalCopyClass() { } INonCopyNormalClass* YetAnotherNonNormalCopyClass::clone() { return new YetAnotherNonNormalCopyClass(*this); } It is quite important that the DLL_API is defined properly !! This seems to be the reason, that the code above compile, links and runs. This should not be possible. The line return new YetAnotherNonNormalCopyClass(*this); should not work. If DLL_API is undefined or removed, you will get the correct error message and compilation fails ANY ideas ? SOMEONE ? Thanks and best, Philipp

1 0

[Boost.Asio] asio objects: initializing after construction
by Roman Shmelev 12 Oct '08

12 Oct '08

Hi! Lets assume I have some kind of map : map<int, boost::asio::ip::tcp::acceptor> my_acceptors; AND map<int, boost::asio::ip::tcp::socket> my_sockets; I want to extend the maps with new objects, so what is the right way to (?): my_acceptors[someport_int].initialize(_my_ioservice,_my_endpoint); my_acceptors[another_int].initialize(_my_ioservice); I use such code, but not sure it is right: { // initialize new acceptor ip::tcp::endpoint _my_endpoint(ip::tcp::v4(),port); ip::tcp::acceptor _acc(_my_ioservice,_my_endpoint); my_acceptors[someport_int] = _acc; // initialize new socket ip::tcp::socket _thesock(_my_ioservice); my_sockets[another_int] = _thesock; // asycc_accept my_acceptors[someport_int].async_accept(my_sockets[new_neighbour_id],boost::bind(do_AsyncAcceptHandler,this,new_neighbour_id)); } Thanks!

3 3

static library link (unit test) to msvc 2008
by Boost fan 12 Oct '08

12 Oct '08

Hi, I managed to make the static library work on msvc. some notes: 1.The compiler throws many exeptions on enable_if.hpp , although I had just included <unit_test.hpp>. As a work-around (hack?) #define BOOST_UTILITY_ENABLE_IF_HPP was used before inclusion. 2.The simple tests apparently works but I dont know how to manage dynamic ones (asserts) ; currently ( assert(x)-->Assert(x) ): #ifdef TEST_MODE # define Assert(x) BOOST_CHECK(x) #else # define Assert(x) do{}while(0) #endif There are some strange run time errors which debugging doesnt lead to exact code. Now any comments on these ? :)

1 0

Re: [Boost-users] msvc 64-bit test targets vs. manifest files
by Mat Marcus 12 Oct '08

12 Oct '08

Posted to boost build list without any reply. Now trying boost users: > For several years I have been working with a set of libraries, built > with boost build and dependent upon some boost libraries. I've been > working on a 32-bit machine, but I have occasionally been building > 64-bit targets to try to help support clients who will be using my > library on 64-bit machines. My suite of boost-build test targets > (unit-test, run, etc.) for my lib is a bit inconvenient when on 32 bit > machines, since I get an error dialog each time I build, but sometimes > I want to test as much as possible. The commands I use to build (msvc > 9) are: > > ## 32 bit > bjam msvc debug > > ## 64 bit > bjam msvc debug architecture=x86 address-model=64 > define=BOOST_DISABLE_ABI_HEADERS > > Yesterday, I tried to build/run the 64 bit targets for the same files > using the same invocation on a 64-bit Vista machine. I thought that > perhaps my code would exhibit some 64-bit run-time issues, but things > didn't go that far. Instead, I got manifest/DLL-related problems for > each test. Here is an example of the error that I receive each time > boost build tries to run a built artifact: > > ====== BEGIN OUTPUT ====== > The application has failed to start because its side-by-side > configuration is incorrect. Please see the application event log for > more detail. > > EXIT STATUS: 14001 > ====== END OUTPUT ====== > > The corresponding Application Event Log Entry is: > > Activation context generation failed for > "c:\asl\staff\mmarcus\sandbox\built_artifacts\documentation\examples\enum_ops_example.test\msvc-9.0\debug\address-model-64\architecture-x86\link-static\threading-multi\enum_ops_example.exe". > Dependent Assembly > Microsoft.VC90.DebugCRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" > could not be found. Please use sxstrace.exe for detailed diagnosis. > > Can someone suggest a workaround or a patch? Thanks, > Mat >

1 0

Re: [Boost-users] Error:" Non-const function called for const object" on Sun CC while using boost::multi_index::multi_index_container
by JOAQUIN M. LOPEZ MUÑOZ 12 Oct '08

12 Oct '08

________________________________________ De: Alexander Vinokur [Alexander.Vinokur(a)amdocs.com] Enviado el: domingo, 12 de octubre de 2008 8:44 Para: boost-users(a)lists.boost.org CC: JOAQUIN M. LOPEZ MUÑOZ Asunto: Re: Error:" Non-const function called for const object" on Sun CC while using boost::multi_index::multi_index_container > > Hi Joaquín, > > I was out of office several days. Sorry. > So, I send my reply today. No problem at all :) > I don't have permissions to change something under /boost. Maybe you can still perform the test by doing the following: 1 Create a local folder structure more or less like this: ~alex/boost_patch/boost/detail and copy there the allocator_utilities.hpp modified file I sent you previously. 2 When compiling your multi-index example add a compiler option (or IDE setting, etc.) so that ~alex/boost_patch/ is added to the list of include directories *and* takes precedence over the official copy of Boost. If you finally manage to do the test please report back your results. > But here other test I did: [example core snipped] I take this a sufficient evidence that the patch should work, so I went ahead and added it to the trunk: http://svn.boost.org/trac/boost/changeset/49289 If nothing wrong happens with the patch, it'll be shipped with Boost 1.38. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [Boost-users] Error:" Non-const function called for const object" on Sun CC while using boost::multi_index::multi_index_container
by Alexander Vinokur 12 Oct '08

12 Oct '08

Hi Joaquín, I was out of office several days. Sorry. So, I send my reply today. I don't have permissions to change something under /boost. But here other test I did: --- file foo19.cpp --- struct Bar { virtual ~Bar(){} }; int main() { const Bar* p1 = new Bar; const_cast<Bar*>(p1)->~Bar(); // No problem const Bar* p2 = new Bar; p2->~Bar(); // line 13: Error: Non-const function Bar::__SLIP.DELETER__A() called for const object. return 0; } ------------------- Compilation: %CC -m64 -library=stlport4 foo19.cpp ==================================================== "JOAQUIN M. LOPEZ MU?OZ" <joaquin(a)tid.es> wrote in message news:<D1B8B06869125E44A4B33FF31CBAEA591187ADF179(a)EXCLU2K7.hi.inet>... De: Alexander Vinokur [Alexander.Vinokur(a)amdocs.com] Enviado el: martes, 07 de octubre de 2008 18:28 Para: boost-users(a)lists.boost.org CC: JOAQUIN M. LOPEZ MU?OZ Asunto: RE: Error:" Non-const function called for const object" on Sun CC w=ile using boost::multi_index::multi_index_container > > Joaquin, thank you. > > Here code I compiled. > > // --- File foo3.cpp --- > [...] > const Bar* p4 = new Bar; > p4->~Bar(); // line 19: Error: Non-const function > Bar::__SLIP.DELETER__A() called for const object. OK, seems like the bug we were after, if only in a slightly different guise (deleting a const T* works, but directly calling ~T() on a const object does not). Alex, can you do the following? Please try replacing the /boost/detail/allocator_utilities.hpp file in your local Boost copy with the attached file and rebuild the multi_index_container code that was failing. Does this fix it? If so, I'll commit this version into th= trunk so that it'll be available in Boost 1.38 (though you can use it now with your local Boost copy, of course). Joaqu?n M L?pez Mu?oz Telef?nica, Investigaci?n y Desarrollo ---------- This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp

1 0