У меня есть этот странный стек вызовов, и я не понимаю, почему.
Мне кажется, что asio вызывает open ssl read, а затем получает отрицательное возвращаемое значение (-37).
Похоже, что затем Asio пытается использовать его внутри функции memcpy.
Функция, вызывающая этот стек вызовов, используется сотни тысяч раз без этой ошибки.
Бывает редко, примерно раз в неделю.
ulRead = (boost::asio::read(spCon->socket(), boost::asio::buffer(_requestHeader, _requestHeader.size()), boost::asio::transfer_at_least(_requestHeader.size()), error_));
Обратите внимание, что размер заголовка запроса всегда составляет ровно 3 байта.
Может ли кто-нибудь пролить свет на возможные причины?
Примечание: я использую boost asio 1.36
Вот сбой стека вызовов в memcpy из-за огромного "счетчика":
Я не уверен в этом, но 4294967259, поскольку число со знаком будет -37
@Brian R. Bondy: Похоже, что-то Плохо происходит в _EVP_CIPHER_set_asn1_iv. Возможно, данные где-то стираются медленно (вы заметили, что это происходит постепенно с течением времени). В конечном итоге это привело к безвременной смерти memcpy.
Иногда это происходит в тот же день, иногда через пару недель, иногда через неделю. Так что я думаю, что это не что-то постепенное. Но такое случается редко. Хорошо, так вы думаете, что это какой-то тип повреждения памяти в несвязанной части кода?
Обратите внимание, что все соединения используют один и тот же контекст ssl, поэтому в предыдущем вопросе я спросил, нормально ли это.





Беглый взгляд на evp_lib.c показывает, что он пытается извлечь длину из контекста шифра, и в вашем случае получает очень плохое значение (tm). Затем он использует это значение для копирования строки (что и делает memcpy). Я предполагаю, что что-то разрушает ваш шифр, будь то проблема безопасности потоков или чтение большего количества байтов в буфер, чем разрешено.
int EVP_CIPHER_set_asn1_iv(EVP_CIPHER_CTX *c, ASN1_TYPE *type)
{
int i=0,j;
if (type != NULL)
{
j=EVP_CIPHER_CTX_iv_length(c);
OPENSSL_assert(j <= sizeof c->iv);
i=ASN1_TYPE_set_octetstring(type,c->oiv,j);
}
return(i);
}
Думаю, я попробую реорганизовать использование контекста SSL и посмотреть, поможет ли это. Большое спасибо за вашу помощь.
@Brian R. Bondy: не проблема, быстрая проверка заключалась бы в том, чтобы поместить что-то перед вашим контекстом в стек и посмотреть, не будет ли это удалено вместо этого.
@ Брайан Р. Бонди: BIO_read возвращает -37?