Hi, I'm trying to serialize a class using two functions located in different DLLs. I can serialize fine by calling one function, but when I call the second it triggers an assertion in extended_type_info.cpp: // make sure that attempt at registration is done only once assert(lookup(eti) == m_self->m_map.end()); Apparently the class is registered twice, but how do I avoid that? -- Anders
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Anders, I had exactly the same problem three days ago. I have found no way to prevent the compiler from instantiating some templates with serialization code in multiple DLLs. My solution was to switch from intrusive to non intrusive serialization and putting all serialization binaries in a third DLL. How it works (for me): 1. Rename all template <class Archive> void serialize(Archive& ar, const unsigned int version) { ... } to template <class Archive> void my_serialize(Archive& ar, const unsigned int version) { ... } and make it public. 2. Remove all serialization headers and macros from the existing code. 3. Create a new DLL. 4. For every serializable class I have there a .cpp file which looks like: #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/serialization/base_object.hpp> #include <boost/serialization/export.hpp> #include "abstracts.h" namespace boost { namespace serialization { template <class Archive> void serialize(Archive& ar, MyClass& obj, const unsigned int version) { obj.template bm_serialize<Archive>(ar, version); } } } BOOST_CLASS_EXPORT(MyClass); BOOST_SHARED_POINTER_EXPORT(MyClass); 5. One additional file abstracts.h which looks like: #ifndef BM_SERIALITATION_ABSTRACTS_H_ #define BM_SERIALITATION_ABSTRACTS_H_ BOOST_IS_ABSTRACT(MyBaseClass) #endif ######################### I'm not sure this is the preferred way to handle things, but at least it works for me. Best regards, Markus Anders Wang Kristensen schrieb:
Hi,
I'm trying to serialize a class using two functions located in different DLLs.
I can serialize fine by calling one function, but when I call the second it triggers an assertion in extended_type_info.cpp:
// make sure that attempt at registration is done only once assert(lookup(eti) == m_self->m_map.end());
Apparently the class is registered twice, but how do I avoid that?
-- Anders
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
- -- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjcNOdnooMonJSYkRAkt5AKCDwPC6miTv4LvKS1R17yPhnxqLxACdHc2H ZgxzA+Uw6G9pkfTdKAsDNfc= =Usz+ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Small typo: Markus Bernhardt schrieb:
Hi Anders,
I had exactly the same problem three days ago. I have found no way to prevent the compiler from instantiating some templates with serialization code in multiple DLLs. My solution was to switch from intrusive to non intrusive serialization and putting all serialization binaries in a third DLL.
How it works (for me):
1. Rename all template <class Archive> void serialize(Archive& ar, const unsigned int version) { ... } to template <class Archive> void my_serialize(Archive& ar, const unsigned int version) { ... } and make it public.
2. Remove all serialization headers and macros from the existing code.
3. Create a new DLL.
4. For every serializable class I have there a .cpp file which looks like:
#include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/serialization/base_object.hpp> #include <boost/serialization/export.hpp> #include "abstracts.h"
namespace boost { namespace serialization { template <class Archive> void serialize(Archive& ar, MyClass& obj, const unsigned int version) { obj.template bm_serialize<Archive>(ar, version);
obj.template my_serialize<Archive>(ar, version); // Correct
} } }
BOOST_CLASS_EXPORT(MyClass); BOOST_SHARED_POINTER_EXPORT(MyClass);
5. One additional file abstracts.h which looks like:
#ifndef BM_SERIALITATION_ABSTRACTS_H_ #define BM_SERIALITATION_ABSTRACTS_H_
BOOST_IS_ABSTRACT(MyBaseClass)
#endif
#########################
I'm not sure this is the preferred way to handle things, but at least it works for me.
Best regards, Markus
Anders Wang Kristensen schrieb:
Hi,
I'm trying to serialize a class using two functions located in different DLLs.
I can serialize fine by calling one function, but when I call the second it triggers an assertion in extended_type_info.cpp:
// make sure that attempt at registration is done only once assert(lookup(eti) == m_self->m_map.end());
Apparently the class is registered twice, but how do I avoid that?
-- Anders
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München
Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de
Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231
- -- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjgXLdnooMonJSYkRAqNjAJ9o5L66WJqa0EIE6NyHsn0eqcl3OQCeJbM6 BJoKVmpudhyz90rmBxI/IAw= =tyTm -----END PGP SIGNATURE-----
Thanks! I'll take a look at your solution. -- Anders "Markus Bernhardt" <Markus.Bernhardt@scmb.de> wrote in message news:468E05CB.9050904@scmb.de... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Small typo: Markus Bernhardt schrieb:
Hi Anders,
I had exactly the same problem three days ago. I have found no way to prevent the compiler from instantiating some templates with serialization code in multiple DLLs. My solution was to switch from intrusive to non intrusive serialization and putting all serialization binaries in a third DLL.
How it works (for me):
1. Rename all template <class Archive> void serialize(Archive& ar, const unsigned int version) { ... } to template <class Archive> void my_serialize(Archive& ar, const unsigned int version) { ... } and make it public.
2. Remove all serialization headers and macros from the existing code.
3. Create a new DLL.
4. For every serializable class I have there a .cpp file which looks like:
#include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/serialization/base_object.hpp> #include <boost/serialization/export.hpp> #include "abstracts.h"
namespace boost { namespace serialization { template <class Archive> void serialize(Archive& ar, MyClass& obj, const unsigned int version) { obj.template bm_serialize<Archive>(ar, version);
obj.template my_serialize<Archive>(ar, version); // Correct
} } }
BOOST_CLASS_EXPORT(MyClass); BOOST_SHARED_POINTER_EXPORT(MyClass);
5. One additional file abstracts.h which looks like:
#ifndef BM_SERIALITATION_ABSTRACTS_H_ #define BM_SERIALITATION_ABSTRACTS_H_
BOOST_IS_ABSTRACT(MyBaseClass)
#endif
#########################
I'm not sure this is the preferred way to handle things, but at least it works for me.
Best regards, Markus
Anders Wang Kristensen schrieb:
Hi,
I'm trying to serialize a class using two functions located in different DLLs.
I can serialize fine by calling one function, but when I call the second it triggers an assertion in extended_type_info.cpp:
// make sure that attempt at registration is done only once assert(lookup(eti) == m_self->m_map.end());
Apparently the class is registered twice, but how do I avoid that?
-- Anders
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München
Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de
Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231
- -- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjgXLdnooMonJSYkRAqNjAJ9o5L66WJqa0EIE6NyHsn0eqcl3OQCeJbM6 BJoKVmpudhyz90rmBxI/IAw= =tyTm -----END PGP SIGNATURE-----
I believe you could have left the intrusive versions. Rather than use inline implementations, move the implementations of the serialize functions into a single module. Robert Ramey Markus Bernhardt wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Anders,
I had exactly the same problem three days ago. I have found no way to prevent the compiler from instantiating some templates with serialization code in multiple DLLs. My solution was to switch from intrusive to non intrusive serialization and putting all serialization binaries in a third DLL.
Ensure that the serialization code is in one DLL by having some function like: MyClass * deserializeMyClass(std::istream & is); And call that from either dll. Then all the serialization magic is hidden (and instantiated) in one dll and you don't need to worry about cross-dll template/static/ARGH! HTH and good luck! -----Original Message----- From: boost-users-bounces@lists.boost.org on behalf of Anders Wang Kristensen Sent: Thu 7/5/2007 4:57 PM To: boost-users@lists.boost.org Subject: [Boost-users] [serialization] DLL woes Hi, I'm trying to serialize a class using two functions located in different DLLs. I can serialize fine by calling one function, but when I call the second it triggers an assertion in extended_type_info.cpp: // make sure that attempt at registration is done only once assert(lookup(eti) == m_self->m_map.end()); Apparently the class is registered twice, but how do I avoid that? -- Anders _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
That solution is really impractical, IMHO. If this is really the only solution, I would consider the serialization lib broken wrt to DLLs, and that should be in the docs somewhere. That's really too bad, since it is such a nice and useful library! I.e. how would you solve the following, if A and B are unrelated libraries in seperate DLLs sharing a class X that is serialized as part of serializing A and B? //dll A struct A { X x; }; //dll B struct B { X x; }; Placing the serialization code for both libraries in a third io.dll means that any program using just one of A or B becomes dependent on both A and B (since io.dll must link to both A and B). And if you added a struct C { X x; }; it would be even worse.. -- Anders ----------------------------------------- "Sohail Somani" <s.somani@fincad.com> wrote in message news:1C1EBEF8DBACDC439D038EA051674EC73EE2A3@xbox.financialcad.com... Ensure that the serialization code is in one DLL by having some function like: MyClass * deserializeMyClass(std::istream & is); And call that from either dll. Then all the serialization magic is hidden (and instantiated) in one dll and you don't need to worry about cross-dll template/static/ARGH! HTH and good luck! -----Original Message----- From: boost-users-bounces@lists.boost.org on behalf of Anders Wang Kristensen Sent: Thu 7/5/2007 4:57 PM To: boost-users@lists.boost.org Subject: [Boost-users] [serialization] DLL woes Hi, I'm trying to serialize a class using two functions located in different DLLs. I can serialize fine by calling one function, but when I call the second it triggers an assertion in extended_type_info.cpp: // make sure that attempt at registration is done only once assert(lookup(eti) == m_self->m_map.end()); Apparently the class is registered twice, but how do I avoid that? -- Anders _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Anders Wang Kristensen wrote:
That solution is really impractical, IMHO. If this is really the only solution, I would consider the serialization lib broken wrt to DLLs, and that should be in the docs somewhere.
That's really too bad, since it is such a nice and useful library!
I.e. how would you solve the following, if A and B are unrelated libraries in seperate DLLs sharing a class X that is serialized as part of serializing A and B?
Place code to implement X in its own DLL. Robert Ramey
If you mean place everything related to serialization in one DLL, then yes, that will obviously work. But in practice that's hardly a useful solution, since then any library that depends on X now depends on all other libraries that depend on X. I've looked at the register_type function (I assume it is related to this), but I'm not too familiar with the inner workings of the serialization lib. What is it exactly that is registered for each type and why is it an error if this occurs twice?
Place code to implement X in its own DLL.
Robert Ramey
What I mean is that everything related to a implementation of a particular class in one DLL. That is one DLL for A, another for B, and another for X. This wll give a) code for a given class x will be in one and only one dll thereby avoiding issue related to having the same code in different modules. b) DLLS will be no larger than necessary c) runtime memory requirements will be minimized. Robert Ramey Anders Wang Kristensen wrote:
If you mean place everything related to serialization in one DLL, then yes, that will obviously work.
But in practice that's hardly a useful solution, since then any library that depends on X now depends on all other libraries that depend on X.
I've looked at the register_type function (I assume it is related to this), but I'm not too familiar with the inner workings of the serialization lib. What is it exactly that is registered for each type and why is it an error if this occurs twice?
Place code to implement X in its own DLL.
Robert Ramey
Thanks for taking time to answer this. The situation you describe is exactly what I have and what is causing the assert. X is implemented in its own DLL including its serialize function, which is in the cpp file and explicitly instantized with the xml archive. In A and B have their own DLLs and call X::serialize as part of their own serialization. Serializing one works, but both fails. Are you saying this should work? "Robert Ramey" <ramey@rrsd.com> wrote in message news:f6lrfd$hr0$1@sea.gmane.org...
What I mean is that everything related to a implementation of a particular class in one DLL. That is one DLL for A, another for B, and another for X. This wll give
a) code for a given class x will be in one and only one dll thereby avoiding issue related to having the same code in different modules.
b) DLLS will be no larger than necessary
c) runtime memory requirements will be minimized.
Robert Ramey
Anders Wang Kristensen wrote:
If you mean place everything related to serialization in one DLL, then yes, that will obviously work.
But in practice that's hardly a useful solution, since then any library that depends on X now depends on all other libraries that depend on X.
I've looked at the register_type function (I assume it is related to this), but I'm not too familiar with the inner workings of the serialization lib. What is it exactly that is registered for each type and why is it an error if this occurs twice?
Place code to implement X in its own DLL.
Robert Ramey
Anders Wang Kristensen wrote:
Thanks for taking time to answer this.
The situation you describe is exactly what I have and what is causing the assert. X is implemented in its own DLL including its serialize function, which is in the cpp file and explicitly instantized with the xml archive.
In A and B have their own DLLs and call X::serialize as part of their own serialization. Serializing one works, but both fails.
Are you saying this should work?
I'm saying I would expect that to work. If it doesn't I would be curious to learn more about the specific case. I should say when I wrote the library, I didn't really consider the problem of code in DLLs being loaded/unloaded on the fly. This can create a problem as we have a registry to keep track of pointers to certain code addresses. I have made some adjustments to address this in 1.35 - but really haven't set up a way to exhaustively test them. The same can be said for making the serialization library truely threadsafe. Robert Ramey
"Robert Ramey" <ramey@rrsd.com> wrote in message news:f6m0tl$654$1@sea.gmane.org...
Anders Wang Kristensen wrote:
Thanks for taking time to answer this.
The situation you describe is exactly what I have and what is causing the assert. X is implemented in its own DLL including its serialize function, which is in the cpp file and explicitly instantized with the xml archive.
In A and B have their own DLLs and call X::serialize as part of their own serialization. Serializing one works, but both fails.
Are you saying this should work?
I'm saying I would expect that to work. If it doesn't I would be curious to learn more about the specific case.
I should say when I wrote the library, I didn't really consider the problem of code in DLLs being loaded/unloaded on the fly.
This can create a problem as we have a registry to keep track of pointers to certain code addresses. I have made some adjustments to address this in 1.35 - but really haven't set up a way to exhaustively test them.
The same can be said for making the serialization library truely threadsafe.
Robert Ramey
I've attached some files with a simple example that fails. They should be compiled as an executable and three DLLs. This simple example works fine with the assertion in extended_type_info.cpp line 76 removed, though I havent tested that on my "real" code yet.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm using purify to check my app. Using serialization, I see the following FMR: ################# FMR: Free memory read This is occurring while in thread 3: std::locale::~locale() [libstlport.so.1] boost::scoped_ptr<std::locale>::~scoped_ptr() boost::archive::basic_binary_iprimitive<boost::archive:: binary_iarchive,std::basic_istream <char,std::char_traits<char> > >::~basic_binary_iprimitive() boost::archive::binary_iarchive_impl <boost::archive::binary_iarchive>::~binary_iarchive_impl() boost::archive::binary_iarchive::~binary_iarchive() void de::scmb::bm::seri::Serializer::serialize (std::basic_ifstream<char,std::char_traits<char> >&, de::scmb::bm::core::Instance&) Reading 8 bytes from 0x100312228 in the heap. Address 0x100312228 is at the beginning of a freed block of 80 bytes. This block was allocated from thread 3: malloc [rtlib.o] c2n6Fl_Pv___1 [libCrun.so.1] void*operator new(unsigned long) [rtlib.o] std::locale::locale(std::_Locale_impl*,bool) [libstlport.so.1] std::locale::locale<boost::archive::codecvt_null<char> > (const std::locale&,__type_0*) [libboost_serialization-sw-d.a] std::locale*boost::archive::add_facet <boost::archive::codecvt_null<char> >(const std::locale&,__type_0*) [libboost_serialization-sw-d.a] There have been 0 frees since this block was freed from thread 3: free [rtlib.o] c2k6FPv_v___1 [libCrun.so.1] void operator delete(void*) [rtlib.o] boost::io::basic_ios_locale_saver <char,std::char_traits<char> >::~basic_ios_locale_saver() [libboost_serialization-sw-d.a] boost::archive::basic_binary_iprimitive <boost::archive::binary_iarchive,std::basic_istream <char,std::char_traits<char> > >::~basic_binary_iprimitive() [libboost_serialization-sw-d.a] boost::archive::binary_iarchive_impl <boost::archive::binary_iarchive>::~binary_iarchive_impl() [Serializer.cpp] ################# Has anyone seen this before. Looks like std::locale is using a buffer with 80 bytes size, which is shared between std::locale objetcs and get deleted by the destruction of a basic_ios_locale_saver object, which has a std::locale object. Is this guess correct ?? Can this become a problem ?? Kind regards, Markus - -- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjhqydnooMonJSYkRAuNnAJ47I+Q2/xagCxw5H/pzDLl50ragJACbBQyx vDtVBQkEe407mIYX1Y6dvzg= =GgUq -----END PGP SIGNATURE-----
Wouldn't this be an issue to be addressed in the "i/o state saver" library? Robert Ramey Markus Bernhardt wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I'm using purify to check my app. Using serialization, I see the following FMR:
#################
FMR: Free memory read This is occurring while in thread 3: std::locale::~locale() [libstlport.so.1] boost::scoped_ptr<std::locale>::~scoped_ptr() boost::archive::basic_binary_iprimitive<boost::archive:: binary_iarchive,std::basic_istream <char,std::char_traits<char> > >::~basic_binary_iprimitive() boost::archive::binary_iarchive_impl <boost::archive::binary_iarchive>::~binary_iarchive_impl()
boost::archive::binary_iarchive::~binary_iarchive() void de::scmb::bm::seri::Serializer::serialize (std::basic_ifstream<char,std::char_traits<char> >&, de::scmb::bm::core::Instance&)
Reading 8 bytes from 0x100312228 in the heap. Address 0x100312228 is at the beginning of a freed block of 80 bytes.
This block was allocated from thread 3: malloc [rtlib.o] c2n6Fl_Pv___1 [libCrun.so.1] void*operator new(unsigned long) [rtlib.o] std::locale::locale(std::_Locale_impl*,bool) [libstlport.so.1] std::locale::locale<boost::archive::codecvt_null<char> > (const std::locale&,__type_0*) [libboost_serialization-sw-d.a] std::locale*boost::archive::add_facet <boost::archive::codecvt_null<char> >(const std::locale&,__type_0*) [libboost_serialization-sw-d.a]
There have been 0 frees since this block was freed from thread 3: free [rtlib.o] c2k6FPv_v___1 [libCrun.so.1] void operator delete(void*) [rtlib.o] boost::io::basic_ios_locale_saver <char,std::char_traits<char> >::~basic_ios_locale_saver() [libboost_serialization-sw-d.a] boost::archive::basic_binary_iprimitive <boost::archive::binary_iarchive,std::basic_istream <char,std::char_traits<char> > >::~basic_binary_iprimitive() [libboost_serialization-sw-d.a] boost::archive::binary_iarchive_impl <boost::archive::binary_iarchive>::~binary_iarchive_impl() [Serializer.cpp]
#################
Has anyone seen this before.
Looks like std::locale is using a buffer with 80 bytes size, which is shared between std::locale objetcs and get deleted by the destruction of a basic_ios_locale_saver object, which has a std::locale object.
Is this guess correct ??
Can this become a problem ??
Kind regards, Markus
- -- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München
Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de
Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGjhqydnooMonJSYkRAuNnAJ47I+Q2/xagCxw5H/pzDLl50ragJACbBQyx vDtVBQkEe407mIYX1Y6dvzg= =GgUq -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 @ Ramey: sorry. I Haven't known there's a seperate project for this. @ all: I'm using: Boost 1.32.0 OS: Solaris 10 64-bit Sparc and AMD64 CC: Sun C++ 5.8 Patch 121018-10 2007/02/21 Kind regards, Markus Robert Ramey schrieb:
Wouldn't this be an issue to be addressed in the "i/o state saver" library?
Robert Ramey
Markus Bernhardt wrote: Hi,
I'm using purify to check my app. Using serialization, I see the following FMR:
#################
FMR: Free memory read This is occurring while in thread 3: std::locale::~locale() [libstlport.so.1] boost::scoped_ptr<std::locale>::~scoped_ptr() boost::archive::basic_binary_iprimitive<boost::archive:: binary_iarchive,std::basic_istream <char,std::char_traits<char> > >::~basic_binary_iprimitive() boost::archive::binary_iarchive_impl <boost::archive::binary_iarchive>::~binary_iarchive_impl()
boost::archive::binary_iarchive::~binary_iarchive() void de::scmb::bm::seri::Serializer::serialize (std::basic_ifstream<char,std::char_traits<char> >&, de::scmb::bm::core::Instance&)
Reading 8 bytes from 0x100312228 in the heap. Address 0x100312228 is at the beginning of a freed block of 80 bytes.
This block was allocated from thread 3: malloc [rtlib.o] c2n6Fl_Pv___1 [libCrun.so.1] void*operator new(unsigned long) [rtlib.o] std::locale::locale(std::_Locale_impl*,bool) [libstlport.so.1] std::locale::locale<boost::archive::codecvt_null<char> > (const std::locale&,__type_0*) [libboost_serialization-sw-d.a] std::locale*boost::archive::add_facet <boost::archive::codecvt_null<char> >(const std::locale&,__type_0*) [libboost_serialization-sw-d.a]
There have been 0 frees since this block was freed from thread 3: free [rtlib.o] c2k6FPv_v___1 [libCrun.so.1] void operator delete(void*) [rtlib.o] boost::io::basic_ios_locale_saver <char,std::char_traits<char> >::~basic_ios_locale_saver() [libboost_serialization-sw-d.a] boost::archive::basic_binary_iprimitive <boost::archive::binary_iarchive,std::basic_istream <char,std::char_traits<char> > >::~basic_binary_iprimitive() [libboost_serialization-sw-d.a] boost::archive::binary_iarchive_impl <boost::archive::binary_iarchive>::~binary_iarchive_impl() [Serializer.cpp]
#################
Has anyone seen this before.
Looks like std::locale is using a buffer with 80 bytes size, which is shared between std::locale objetcs and get deleted by the destruction of a basic_ios_locale_saver object, which has a std::locale object.
Is this guess correct ??
Can this become a problem ??
Kind regards, Markus
-- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München
Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de
Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231
------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
- -- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGjmcHdnooMonJSYkRAkTKAJ4g4C7H6llAUvsu7YGCo1lNsPG3lwCfZCvW wHA2T/RpjuDE/77Csdu5FXg= =nS3m -----END PGP SIGNATURE-----
BTW - I'm not sure where this problem is located. I just found a stream.sync in the destructor or the archive - this seems to me that it should be OK from looking at it. Really I have no idea about this. Robert Ramey Markus Bernhardt wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
@ Ramey: sorry. I Haven't known there's a seperate project for this.
@ all:
I'm using: Boost 1.32.0 OS: Solaris 10 64-bit Sparc and AMD64 CC: Sun C++ 5.8 Patch 121018-10 2007/02/21
Kind regards, Markus
Robert Ramey schrieb:
Wouldn't this be an issue to be addressed in the "i/o state saver" library?
Robert Ramey
Markus Bernhardt wrote: Hi,
I'm using purify to check my app. Using serialization, I see the following FMR:
#################
FMR: Free memory read This is occurring while in thread 3: std::locale::~locale() [libstlport.so.1] boost::scoped_ptr<std::locale>::~scoped_ptr() boost::archive::basic_binary_iprimitive<boost::archive:: binary_iarchive,std::basic_istream <char,std::char_traits<char> > >::~basic_binary_iprimitive() boost::archive::binary_iarchive_impl <boost::archive::binary_iarchive>::~binary_iarchive_impl()
boost::archive::binary_iarchive::~binary_iarchive() void de::scmb::bm::seri::Serializer::serialize (std::basic_ifstream<char,std::char_traits<char> >&, de::scmb::bm::core::Instance&)
Reading 8 bytes from 0x100312228 in the heap. Address 0x100312228 is at the beginning of a freed block of 80 bytes.
This block was allocated from thread 3: malloc [rtlib.o] c2n6Fl_Pv___1 [libCrun.so.1] void*operator new(unsigned long) [rtlib.o] std::locale::locale(std::_Locale_impl*,bool) [libstlport.so.1] std::locale::locale<boost::archive::codecvt_null<char> > (const std::locale&,__type_0*) [libboost_serialization-sw-d.a] std::locale*boost::archive::add_facet <boost::archive::codecvt_null<char> >(const std::locale&,__type_0*) [libboost_serialization-sw-d.a]
There have been 0 frees since this block was freed from thread 3: free [rtlib.o] c2k6FPv_v___1 [libCrun.so.1] void operator delete(void*) [rtlib.o] boost::io::basic_ios_locale_saver <char,std::char_traits<char> >::~basic_ios_locale_saver() [libboost_serialization-sw-d.a] boost::archive::basic_binary_iprimitive <boost::archive::binary_iarchive,std::basic_istream <char,std::char_traits<char> > >::~basic_binary_iprimitive() [libboost_serialization-sw-d.a] boost::archive::binary_iarchive_impl <boost::archive::binary_iarchive>::~binary_iarchive_impl() [Serializer.cpp]
#################
Has anyone seen this before.
Looks like std::locale is using a buffer with 80 bytes size, which is shared between std::locale objetcs and get deleted by the destruction of a basic_ios_locale_saver object, which has a std::locale object.
Is this guess correct ??
Can this become a problem ??
Kind regards, Markus
-- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München
Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de
Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231
------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
- -- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München
Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de
Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGjmcHdnooMonJSYkRAkTKAJ4g4C7H6llAUvsu7YGCo1lNsPG3lwCfZCvW wHA2T/RpjuDE/77Csdu5FXg= =nS3m -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is harmfull. Although my unittests are working correct, my application crashes with real life data after serializing 25GB data to disk in the destructor ~basic_binary_iprimitive. I will setup an analysis with real life data, but this will take a while, because the debugger slows things "a little bit". I have an idea what perhaps causes the problem and will look into it. Kind regards, Markus Markus Bernhardt schrieb:
@ Ramey: sorry. I Haven't known there's a seperate project for this.
@ all:
I'm using: Boost 1.32.0 OS: Solaris 10 64-bit Sparc and AMD64 CC: Sun C++ 5.8 Patch 121018-10 2007/02/21
Kind regards, Markus
Robert Ramey schrieb:
Wouldn't this be an issue to be addressed in the "i/o state saver" library?
Robert Ramey
Markus Bernhardt wrote: Hi,
I'm using purify to check my app. Using serialization, I see the following FMR:
#################
FMR: Free memory read This is occurring while in thread 3: std::locale::~locale() [libstlport.so.1] boost::scoped_ptr<std::locale>::~scoped_ptr() boost::archive::basic_binary_iprimitive<boost::archive:: binary_iarchive,std::basic_istream <char,std::char_traits<char> > >::~basic_binary_iprimitive() boost::archive::binary_iarchive_impl <boost::archive::binary_iarchive>::~binary_iarchive_impl()
boost::archive::binary_iarchive::~binary_iarchive() void de::scmb::bm::seri::Serializer::serialize (std::basic_ifstream<char,std::char_traits<char> >&, de::scmb::bm::core::Instance&)
Reading 8 bytes from 0x100312228 in the heap. Address 0x100312228 is at the beginning of a freed block of 80 bytes.
This block was allocated from thread 3: malloc [rtlib.o] c2n6Fl_Pv___1 [libCrun.so.1] void*operator new(unsigned long) [rtlib.o] std::locale::locale(std::_Locale_impl*,bool) [libstlport.so.1] std::locale::locale<boost::archive::codecvt_null<char> > (const std::locale&,__type_0*) [libboost_serialization-sw-d.a] std::locale*boost::archive::add_facet <boost::archive::codecvt_null<char> >(const std::locale&,__type_0*) [libboost_serialization-sw-d.a]
There have been 0 frees since this block was freed from thread 3: free [rtlib.o] c2k6FPv_v___1 [libCrun.so.1] void operator delete(void*) [rtlib.o] boost::io::basic_ios_locale_saver <char,std::char_traits<char> >::~basic_ios_locale_saver() [libboost_serialization-sw-d.a] boost::archive::basic_binary_iprimitive <boost::archive::binary_iarchive,std::basic_istream <char,std::char_traits<char> > >::~basic_binary_iprimitive() [libboost_serialization-sw-d.a] boost::archive::binary_iarchive_impl <boost::archive::binary_iarchive>::~binary_iarchive_impl() [Serializer.cpp]
#################
Has anyone seen this before.
Looks like std::locale is using a buffer with 80 bytes size, which is shared between std::locale objetcs and get deleted by the destruction of a basic_ios_locale_saver object, which has a std::locale object.
Is this guess correct ??
Can this become a problem ??
Kind regards, Markus
-- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München
Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de
Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231
------------------------------------------------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München
Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de
Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231
- -- Software Consulting Markus Bernhardt GmbH Spieljochstr. 34 81825 München Fon: +49-89-420903-14 Fax: +49-89-420903-20 www: http://www.scmb.de Geschäftsführung Markus Bernhardt Handelsregister AG München HRB 125966 USt-Id DE201885231 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGj38VdnooMonJSYkRAtNNAJ9zPmOPmeBRiavxhH5N/UdLd0/cIACfZyyB RvR2jAWuYcmwSI2oJzG/tX4= =Pkf9 -----END PGP SIGNATURE-----
participants (3)
-
Anders Wang Kristensen -
Markus Bernhardt -
Robert Ramey -
Sohail Somani