Следующая проблема извлечена из огромного проекта и самого минимального примера проблемы, которую я смог придумать.
Я знаю, исходя из std::string
это плохо, и это уже изменилось в нашей кодовой базе, но я пытаюсь понять, что здесь происходит под капотом.
Код вылетает на Visual C ++ 2017
Microsoft Visual Studio Community 2017
Version 15.2 (26430.14) Release
Visual C++ 2017 00369-60000-00001-AA257
только в режиме релиза (с оптимизацией скорости). Не сбой в режиме релиза без оптимизации скорости.
#include <string>
#include <string_view>
#include <vector>
struct my_string : public std::string
{
__declspec(noinline)
my_string::my_string( const std::string_view& str ) :
std::string( str.data(), str.size() )
{}
template <typename T>
my_string& arg( T )
{
return *this;
}
};
struct my_string_view : public std::string_view
{
my_string_view( const std::string_view::value_type* val ) :
std::string_view( val ) {}
template <typename... PARAMS>
my_string arg( PARAMS&&... prms ) {
return my_string( *this ).arg( std::forward<PARAMS>( prms )... );
}
};
template <typename T>
struct basic_color
{
T r, g, b, a;
basic_color() : r( 0 ), g( 0 ), b( 0 ), a( 255 ) {}
template <typename U>
explicit basic_color( const basic_color<U>& c ) :
r( c.r ), g( c.g ), b( c.b ), a( c.a )
{}
};
using color = basic_color<std::uint8_t>;
using float_color = basic_color<float>;
__declspec(noinline)
void change_float_color( float_color& color )
{
color.r = 0.1f;
}
int main()
{
std::vector<float_color> colors = { {} };
float sum = 0;
for ( std::uint32_t i = 0; i < 1; ++i )
{
float_color fc;
change_float_color( fc );
color c( fc );
std::vector<std::string> msgs;
msgs.push_back( my_string_view( "" ).arg( c.r ) );
msgs.push_back( my_string_view( "" ).arg( c.g ) );
sum += fc.b - colors[i].b;
}
return static_cast<int>(sqrt( sum ));
}
Ошибка в Visual Studio заключается в следующем (посмотрите на разбитые размеры msgs
а также colors
внизу):
Я думаю, что зов std::vector<std::string>::push_back(std::string&&)
с my_string
проблематично (поведение, похожее на нарезку). Но как это может повредить стек (или указатель стека)?
У кого-нибудь есть идея, что здесь может происходить или как я могу это выяснить?
Вот мой проект на тот случай, если кто-то заинтересован в воспроизведении проблемы.
Я думаю, что это ошибка компилятора.
Вот что я вижу по разборке: по факту main()
запись, esp
сохраняется в ebx
, В конце, esp
восстанавливается из ebx
, Тем не менее, в середине (после вызова std::_Destroy_range1
) ebx
значение перезаписывается чем-то другим. Итак, в конце концов, ret
инструкция использует фальшивку esp
значение, и переходит на неверное место.
Таким образом, на самом деле, стек не поврежден (эту ошибку нельзя отследить с помощью точек останова данных, как предложил Ханс), но указатель стека есть.
Других решений пока нет …