Hi,
I'm surprised that the Motive API contains functions using std containers, which is against best practices. Indeed, if the client uses a different std version, there is a risk of crash.
STL types (std::string, std::vector, etc.) are not ABI-stable.
Their binary representation and allocation strategy vary between:
- Compiler versions (MSVC, GCC, Clang)
- Standard library implementations (libstdc++, libc++, MSVC STL)
- Build options (_ITERATOR_DEBUG_LEVEL, _GLIBCXX_USE_CXX11_ABI, etc.)
- CRT linkage (/MD vs /MT)
This means passing a std::vector<int> from a DLL built with one configuration to an EXE built with another can lead to heap corruption, crashes, or memory leaks.
And this is exactly what I'm currently facing.
Best regards,
Vincent
MotiveAPI 3.1.0 using std containers !!!
-
steven.andrews
- NaturalPoint Employee
- Posts: 719
- Joined: Mon Jan 19, 2015 11:52 am
Re: MotiveAPI 3.1.0 using std containers !!!
Hi Vincent,
Thank you for the detailed post and for taking the time to call this out. You are correct that exposing STL containers across DLL boundaries can introduce ABI instability, and what you described is consistent with what we would expect if the client build configuration does not match the one Motive was built with.
At present, the Motive API does make use of std:: types in its public interface, which means the DLL and client project must be compiled with compatible compiler versions and flags. Reworking this boundary would require significant refactoring, as there are a number of occurrences of STL types throughout the current API. Because of this, it is not something we can address quickly, but it is something we may look into for the future.
In the meantime, the best workaround is to match your project’s build configuration with the one used by the Motive API samples. You can find those in: C:\Program Files\OptiTrack\Motive\Samples\MotiveAPI
If you can successfully build and run the samples, you can copy that toolchain configuration into your own project to ensure binary compatibility.
We know this is not an ideal long-term solution, but it should help get you unblocked for now.
Best regards,
Steven
Steven Andrews
Sr. Director, Support Engineering
OptiTrack
Thank you for the detailed post and for taking the time to call this out. You are correct that exposing STL containers across DLL boundaries can introduce ABI instability, and what you described is consistent with what we would expect if the client build configuration does not match the one Motive was built with.
At present, the Motive API does make use of std:: types in its public interface, which means the DLL and client project must be compiled with compatible compiler versions and flags. Reworking this boundary would require significant refactoring, as there are a number of occurrences of STL types throughout the current API. Because of this, it is not something we can address quickly, but it is something we may look into for the future.
In the meantime, the best workaround is to match your project’s build configuration with the one used by the Motive API samples. You can find those in: C:\Program Files\OptiTrack\Motive\Samples\MotiveAPI
If you can successfully build and run the samples, you can copy that toolchain configuration into your own project to ensure binary compatibility.
We know this is not an ideal long-term solution, but it should help get you unblocked for now.
Best regards,
Steven
Steven Andrews
Sr. Director, Support Engineering
OptiTrack