greenday9
commented
8 years ago This issue can be reproduced with the following test program.
void post_method_handler( const shared_ptr< Session > session )
{
const auto request = session->get_request( );
size_t content_length = request->get_header( "Content-Length", 0 );
session->fetch( content_length, [ request ]( const shared_ptr< Session > session, const Bytes & body )
{
fprintf( stdout, "%.*s\n", ( int ) body.size( ), body.data( ) );
session->sleep_for( std::chrono::milliseconds(5), []( const shared_ptr< Session > session )
{
session->yield( OK, "Hello, World!", { { "Content-Length", "13" }, { "Connection", "close" } } );
}
);
} );
}
int main( const int, const char** )
{
auto resource = make_shared< Resource >( );
resource->set_path( "/resource" );
resource->set_method_handler( "POST", post_method_handler );
auto settings = make_shared< Settings >( );
settings->set_port( 8010 );
settings->set_worker_limit( 10 );
Service service;
service.publish( resource );
service.start( settings );
return EXIT_SUCCESS;
}
Sending a load of requests into the test program causes it to coredump very quickly. Note that sometimes I see other crashes besides an unhandled exception. It may be a multi-threading issue since I don't see it if I set worker_limit to 1.
ben-crowhurst
callum-kirby
ignitenet-martynas
clrusby
We’ve run into an issue with restbed coredumping due to an unhandled exception.
This was encountered with an application compiled on AWS Linux with gcc 5.4.0
The following error message is generated to stderr when the unhandled exception is encountered.
This is the stack backtrace from the core file which is not too helpful.
Using gdb, I tracked down where std::system_error is being thrown from asio. See below: