#644 Trace of a random crash on windows

[logzero]

Trace obtained from win7/mingw build (may not apply to official svn builds). Posting here to have it documented, just for the case that I can replicate it.

Crash was a singular/unforced event during one of multiple test runs on unrelated functionality.

#0 00CF82B1 std::tr1::_Hashtable<std::string, std::pair<std::string const, unsigned int>, std::allocator<std::pair<std::string const, unsigned int> >, std::_Select1st<std::pair<std::string const, unsigned int> >, std::equal_to<std::string>, std::tr1::hash<std::string>, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, false, true>::_M_erase_node(this=0x1701ec0 <_ZL10stringPool>, __p=0x2945ef20, __b=0x17933474) (c:/mingw/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../include/c++/4.7.2/tr1/hashtable.h:957)
#1 00CF89D8 std::tr1::_Hashtable<std::string, std::pair<std::string const, unsigned int>, std::allocator<std::pair<std::string const, unsigned int> >, std::_Select1st<std::pair<std::string const, unsigned int> >, std::equal_to<std::string>, std::tr1::hash<std::string>, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, false, true>::erase(this=0x1701ec0 <_ZL10stringPool>, __it=...) (c:/mingw/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../include/c++/4.7.2/tr1/hashtable.h:1004)
#2 00ABCFEC SharedPool<std::string, StringpoolTraits>::Reference::unref(this=0x28b040) (../vegastrike/src/SharedPool.h:50)
#3 00ABD103 SharedPool<std::string, StringpoolTraits>::Reference::~Reference(this=0x28b040, __in_chrg=<optimized out>) (../vegastrike/src/SharedPool.h:95)
#4 00AE8B44 Cargo::~Cargo(this=0x28b034, __in_chrg=<optimized out>) (../vegastrike/src/cmd/images.h:131)
#5 00711149 Unit::GetSortedCargoCat(this=0x17707b50, cat=..., begin=@0x28b148: 411, end=@0x28b144: 416) (F:\vegastrike\vegastrike\src\cmd\unit_generic.cpp:8369)
#6 00A1805F UniverseUtil::getRandCargo(quantity=1, category=...) (F:\vegastrike\vegastrike\src\universe_util_generic.cpp:198)
#7 00B7423E boost::python::detail::invoke<boost::python::to_python_value<Cargo const&>, Cargo (*)(int, std::string) (../vegastrike/boost/1_45/boost/python/detail/invoke.hpp:75)
#8 00B3883C boost::python::detail::caller_arity<2u>::impl<Cargo (*)(int, std::string) (../vegastrike/boost/1_45/boost/python/detail/caller.hpp:223)
#9 00B8F643 boost::python::objects::caller_py_function_impl<boost::python::detail::caller<Cargo (*)(int, std::string) (../vegastrike/boost/1_45/boost/python/object/py_function.hpp:38)
#10 00C51800 boost::python::objects::py_function::operator() (this=0xede7d90, args=0x23c97e0c, kw=0x0) (../vegastrike/boost/1_45/boost/python/object/py_function.hpp:143)
#11 00410BC2 boost::python::objects::function::call(this=0xede7d88, args=0x23c97e0c, keywords=0x0) (F:\vegastrike\vegastrike\boost\1_45\src\object\function.cpp:226)
#12 00412855 boost::python::objects::(anonymous namespace)::bind_return::operator()(this=0x28b650) (F:\vegastrike\vegastrike\boost\1_45\src\object\function.cpp:585)
#13 004134AF boost::detail::function::void_function_ref_invoker0<boost::python::objects::{anonymous}::bind_return, void>::invoke(boost::detail::function::function_buffer &) (function_obj_ptr=...) (../vegastrike/boost/1_45/boost/function/function_template.hpp:188)
#14 00C54454 boost::function0<void>::operator() (this=0x28b620) (../vegastrike/boost/1_45/boost/function/function_template.hpp:1013)
#15 00406D22 boost::python::handle_exception_impl(f=...) (F:\vegastrike\vegastrike\boost\1_45\src\errors.cpp:25)
#16 0041314E boost::python::handle_exception<boost::python::objects::{anonymous}::bind_return>(boost::python::objects::(anonymous namespace)::bind_return)(f=...) (../vegastrike/boost/1_45/boost/python/errors.hpp:29)
#17 00412941 boost::python::objects::function_call(func=0xede7d88, args=0x23c97e0c, kw=0x0) (F:\vegastrike\vegastrike\boost\1_45\src\object\function.cpp:626)

[Pheonix Rising]

Does this only happen on the mingw build or have you tried to replicate this under the VC build?

[logzero]

The bug is a SharedPool implementation feature. It is not designed to handle rehashing, as it would invalidate all references. It was triggered due to minimum pool size for string pool singleton not set up correctly in this build.

[logzero]

Can be closed.