views:

318

answers:

1

I have this strange call stack and I am stumped to understand why.

It seems to me that asio calls open ssl's read and then gets a negative return value (-37) .

Asio seems to then try to use it inside the memcpy function.

The function that causes this call stack is used hunderds of thousands of times without this error.

It happens only rarely, about once a week.

ulRead = (boost::asio::read(spCon->socket(), boost::asio::buffer(_requestHeader, _requestHeader.size()), boost::asio::transfer_at_least(_requestHeader.size()), error_));

Note that request header's size is exactly 3 bytes always.

Could anyone shed some light on possible reasons?

Note: I'm using boost asio 1.36

Here is the crashing call stack crash happens in memcpy because of the huge "count":

+2  A: 

A quick look at evp_lib.c shows that it tries to pull a length from the cipher context, and in your case gets a Very Bad Value(tm). It then uses this value to copy a string (which does the memcpy). My guess is something is trashing your cipher, be it a thread safety problem, or a reading more bytes into a buffer than allowed.

Relevant source:

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);
}
sixlettervariables
I think I'll try to refactor the usage of the SSL context and see if it helps. Thanks a ton for your help.
Brian R. Bondy
@Brian R. Bondy: not a problem, a quick check would be to put something before your context on the stack and see if it gets trashed instead.
sixlettervariables