Re: [Boost-users] Buffer overrun error when calling std::exception::what() on boost::asio exception

Subject: Re: [Boost-users] Buffer overrun error when calling std::exception::what() on boost::asio exception
From: Brodie Thiesfield (brofield2_at_[hidden])
Date: 2010-06-02 23:49:13

Nevermind.

This turned out to be a mismatch between my custom built boost libraries
and the application. Probably some compiler settings getting in the way.
I got rid of the custom built boost libs and used the pre-built ones
from boostpro and the problem went away.

I'll work more on what is the problem with my own built version.

Regards,
Brodie

On 2/06/2010 5:54 PM, Brodie Thiesfield wrote:
> Hi,
> 
> OS: Windows
> Compiler: MSVC 2008 SP1 (9.0)
> Boost: 1.43.0
> 
> I am using boost asio, with an implementation of an SSL acceptor. I am
> setting up the context for the SSL, calling "use_private_key_file" on
> boost::asio::ssl::context. The file that I am specifying is invalid or
> doesn't exist, which causes asio to throw an error via:
> 
> boost/asio/ssl/basic_context.hpp:289
>   boost::asio::detail::throw_error(ec);
> 
> I catch the exception in a catch block like:
> 
>     catch (const std::exception& e) {
>         fprintf(stderr, "exception: %s\n", e.what());
>         return false;
>     }
> 
> When I call e.what() everything blows up with a buffer overrun error.
> The stack looks like the following. The m_cat->message() call is causing
> the error (but I can't step into it for some reason).
> 
> boost/system/error_code.hpp:350
>    std::string message() const  { return m_cat->message(value()); }
> boost/system/system_error.hpp:68
>    m_what += m_error_code.message();
> 
> All libraries are built as static libs with the same compiler (OpenSSL,
> Boost). I've tried compiling with BOOST_EXCEPTION_DISABLE defined but it
> makes no difference. I've tried removing the const from the catch
> clause, but no difference.
> 
> Has anyone seen an error like this before? I am frustrated by this error
> and don't know how to look into it further.
> 
> Any suggestions?
> 
> Regards,
> Brodie
>