For the time being, is it possible to use serialization in multi-thread applications using mutexes around serialization methods, or should it totally be avoided? Thanks, Andrej --- Robert Ramey wrote:

It has been determined that the boost serialization - contrary to intention - is not currently thread safe. This will be addressed in a future release.

Robert Ramey

Fei Liu wrote:

...

I am testing a multi-thread app which uses boost serialization library..I got the dreaded error: *** glibc detected *** double free or corruption (fasttop): 0x0aed93d0 *** Aborted

Using a core dump and gdb, here is a backtrace. It appears it crashed inside the multi-thread library. Any advice is appreciated..

#0 0xb7f9a6be in

boost::serialization::extended_type_info::type_info_key_cmp

()

...

from

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

...

(gdb) bt #0 0xb7f9a6be in

boost::serialization::extended_type_info::type_info_key_cmp

()

...

from

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

...

#1 0xb7f9a6f2 in boost::serialization::extended_type_info::operator< () from

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

...

#2 0xb7f9b43e in

std::_Rb_tree

const*,

...

boost::serialization::extended_type_info const*,

std::_Identity

const*>,

...

boost::serialization::detail::tkmap::type_info_compare,

...

std::allocator

const*>

...

...

...

...

insert_unique () from

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

...

#3 0xb7f9adfb in

boost::serialization::extended_type_info::self_register

() from

...

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

#4

...

0x08053c23 in

boost::archive::detail::iserializer

...

std::mapstd::string, std::allocator > >

...

...

...

load_object_data (this=0x805ba7c, ar=@0x933f71e0, x=0x933f73a8, file_version=2470408016) at extended_type_info_typeid.hpp:77 #5 0xb7f91900 in boost::archive::detail::basic_iarchive::load_object () from

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

...

#6 0x080537a7 in

boost::archive::detail::iserializer

...

ns::ge::rule>::load_object_data (this=0x805ba60, ar=@0x933f71e0, x=0x933f73a8, file_version=4) at iserializer.hpp:143 #7 0xb7f91900 in

boost::archive::detail::basic_iarchive::load_object () from

...

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

#8

...

0x08052c82 in utils::xml::deserializens::ge::rule (s=@0x4, is=@0xb7fb7f1e) at iserializer.hpp:143 #9 0x08052f41 in ns::ge::rulesns::ge::rule::process_xml (this=0x805b9a0, xml=@0x933f7410) at ns_ge_rules.h:54 #10 0x08053353 in ns::ge::rule_serverns::ge::rule, pthread::thread_pool> (arg=0xb7fb7f1e) at ns_ge_rule_listener.h:47 #11 0xb7bb73b0 in start_thread () from /lib/tls/libpthread.so.0 #12 0xb79f426e in clone () from /lib/tls/libc.so.6

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org

http://lists.boost.org/mailman/listinfo.cgi/boost-users

___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

I have verified that wrapping static mutex object around serialization methods work. The performance degradation is quite noticeable though. Fei Andrej van der Zee wrote:

For the time being, is it possible to use serialization in multi-thread applications using mutexes around serialization methods, or should it totally be avoided? Thanks, Andrej

--- Robert Ramey wrote:

...

It has been determined that the boost serialization - contrary to intention - is not currently thread safe. This will be addressed in a future release.

Robert Ramey

Fei Liu wrote:

...

I am testing a multi-thread app which uses boost

serialization

...

library..I got the dreaded error: *** glibc detected *** double free or corruption

(fasttop):

...

0x0aed93d0 *** Aborted

Using a core dump and gdb, here is a backtrace. It

appears it crashed

...

inside the multi-thread library. Any advice is

appreciated..

...

#0 0xb7f9a6be in

boost::serialization::extended_type_info::type_info_key_cmp

...

()

...

from

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

...

...

(gdb) bt #0 0xb7f9a6be in

boost::serialization::extended_type_info::type_info_key_cmp

...

()

...

from

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

...

...

#1 0xb7f9a6f2 in

boost::serialization::extended_type_info::operator<

...

() from

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

...

...

#2 0xb7f9b43e in

std::_Rb_tree

...

const*,

...

boost::serialization::extended_type_info const*,

std::_Identity

...

const*>,

boost::serialization::detail::tkmap::type_info_compare,

std::allocator

...

const*>

...

...

...

...

insert_unique () from

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

...

...

#3 0xb7f9adfb in

boost::serialization::extended_type_info::self_register

...

() from

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

...

#4

...

0x08053c23 in

boost::archive::detail::iserializer

...

...

std::map

std::lessstd::string,

...

std::allocator

std::string> > >

...

...

...

...

load_object_data (this=0x805ba7c,

ar=@0x933f71e0, x=0x933f73a8,

...

file_version=2470408016) at

extended_type_info_typeid.hpp:77

...

#5 0xb7f91900 in

boost::archive::detail::basic_iarchive::load_object

...

() from

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

...

...

#6 0x080537a7 in

boost::archive::detail::iserializer

...

...

ns::ge::rule>::load_object_data (this=0x805ba60, ar=@0x933f71e0, x=0x933f73a8, file_version=4)

at

...

iserializer.hpp:143 #7 0xb7f91900 in

boost::archive::detail::basic_iarchive::load_object () from

/usr/lib/libboost_serialization-gcc34-mt-1_34.so.1.34.0

...

#8

...

0x08052c82 in

utils::xml::deserializens::ge::rule (s=@0x4,

...

is=@0xb7fb7f1e) at iserializer.hpp:143 #9

0x08052f41 in

...

ns::ge::rulesns::ge::rule::process_xml

(this=0x805b9a0,

...

xml=@0x933f7410) at ns_ge_rules.h:54 #10

0x08053353 in

...

ns::ge::rule_serverns::ge::rule, pthread::thread_pool> (arg=0xb7fb7f1e) at

ns_ge_rule_listener.h:47

...

#11 0xb7bb73b0 in start_thread () from

/lib/tls/libpthread.so.0 #12

...

0xb79f426e in clone () from /lib/tls/libc.so.6

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org

http://lists.boost.org/mailman/listinfo.cgi/boost-users

___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Andrej van der Zee wrote:

Thanks. That makes the library much less appealing though. Is this threading-bug on all platforms, all compilers, etc? Is it already, or will it be soon fixed in SVN? Cheers, Andrej

Agreed. Atleast Robert has plans to fix it which is good. I believe gcc has the concept of threadsafe statics where dynamic initialization is protected by a mutex so atleast there you should be safe. Sohail