VS2015 unittests and sandbox_vs throw exception

[stevehickman]

Copied the VS2013 solution and upgraded it to VS2015. Built sandbox_vs.exe. Ran sandbox_vs.exe in a command prompt window. It immediately threw an exception:

Debug Assertion Failed!

Program: C:\windows\system32\MSVCP140D.dll
File: c:\program files (x86)\microsoft visual studio 14.0\vc\include\xtree
Line: 237

Expression: map/set iterator not dereferencable

Opening the debugger, it appears that the failure occurs in polymorphic_impl.hpp, line 136 because derivedIter == derivedMap.end(). The call stack shows that this occurs in the creation of cereal::detail::StaticObject via calls to PolymorphicVirtualCaster. The call stack is:

    unittests.exe!cereal::detail::PolymorphicCasters::lookup<void <lambda>(void) >(const std::type_index & baseIndex, const std::type_index & derivedIndex, cereal::detail::PolymorphicVirtualCaster<PolyBaseA,PolyBaseAA>::{ctor}::__l4::std::pair<bool,std::vector<cereal::detail::PolymorphicCaster const *,std::allocator<cereal::detail::PolymorphicCaster const *> > > <lambda>(const std::type_index &, const std::type_index &)::__l2::void <lambda>(void) && exceptionFunc) Line 138   C++
    unittests.exe!cereal::detail::PolymorphicVirtualCaster<PolyBaseA,PolyBaseAA>::{ctor}::__l4::<lambda>(const std::type_index & baseInfo, const std::type_index & derivedInfo) Line 212    C++
    unittests.exe!cereal::detail::PolymorphicVirtualCaster<PolyBaseA,PolyBaseAA>::PolymorphicVirtualCaster<PolyBaseA,PolyBaseAA>() Line 226 C++
>   unittests.exe!cereal::detail::StaticObject<cereal::detail::PolymorphicVirtualCaster<PolyBaseA,PolyBaseAA> >::create() Line 69   C++
    unittests.exe!`dynamic initializer for 'cereal::detail::StaticObject<cereal::detail::PolymorphicVirtualCaster<PolyBaseA,PolyBaseAA> >::instance''() Line 86 C++

The other sandbox exes ran fine. Unittests.exe has the same problem. performance.exe runs fine. Is this an example of the static initialization order fiasco?

[AzothAmmo]

Same issue with VS2013, probably have an export problem with the new polymorphic casting stuff.

[AzothAmmo]

Investigated this a bit more, I believe thie issue is the StaticObject<PolymorphicCasters> created in the DLL being different from the one in the exe. I remember going down this road a long time ago with the StaticObjects for polymorphic type registration, but that was solved by forcing the registration macros to be in headers so the DLL wouldn't be a problem. The proper solution for both is to ensure that the static object is the same across the DLL boundary.

I'll keep looking into this but would appreciate input form anyone more adept at dealing with DLLs on Windows. Everything else is ready to go for the next release once we can get this sorted out.

[stevehickman]

I'm not a DLL expert but I seem to recall running into the same problem with Boost.Serialization several years ago. I'll check to see if it was resolved there. Is it possible to use some kind of compile flag that creates the static object in the DLL and only references it outside the DLL when DLLs are being used?

[stevehickman]

Here's the link to the similar problem I discovered with Boost Serialization. It doesn't appear to be resolved there: https://svn.boost.org/trac/boost/ticket/10084

[dtmoodie]

I've run into a similar issue, I had to put the definition of the registry into a CPP file and I had to make sure the registry was exported correctly.

[AzothAmmo]

Well I finally found time to look at this on a Windows machine.

I think this is actually just a (trivial) bug in the way the code is written - normally we would bail via an exception before dereferencing the invalid iterator if we couldn't find something in a lookup, but in my attempts to re-purpose the function, I had a call to it that didn't actually throw an exception.

I'll be checking in what seems to be a fix shortly, will still need to test on other platforms.