boost::asio problems with returning from io_service

Hello, I actually asked this a little while ago (http://www.cplusplus.com/forum/windows/89824/) and I thought I had it solved but that turned out to be false.
I also asked for help at stackoverflow (http://stackoverflow.com/questions/14753759/boostasio-io-service-doesnt-return-after-stop/) but I wasn't able to solve the problem yet and I decided to ask here too, hoping for more responsiveness.

In my application I am listening for TCP and UDP packets and all the work is being done in the same io_service. I am working under Windows 7 with Visual Studio 2010 and boost 1.51.

Here is the main part of my main function:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
int main(int argc, char* argv[])
{
    //some initializations here

    try
    {
        asio::io_service io_service;
        TcpServer ServerTCP_1(io_service, /*port number here*/);
        TcpServer ServerTCP_2(io_service, /*port number here*/);
        UdpServer ServerUDP(io_service, /*port number here*/);

        io_service.run();
    }
    catch(std::exception& e)
    {
        std::cerr << e.what() << std::endl;
    }

    //cleanup code here

    return 0;
}


and here is the TcpServer Class (which I already modfied according to the answer in stackoverflow):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
class TcpServer : private noncopyable
{
public:
    TcpServer(asio::io_service& io_service, int port) : 
        acceptor_(io_service, tcp::endpoint(tcp::v4(), port)), 
        signals_(io_service), context_(asio::ssl::context::sslv3)
    {
        SSL_CTX_set_cipher_list(context_.native_handle(), "ALL");
        SSL_CTX_set_options(context_.native_handle(), SSL_OP_ALL);
        SSL_CTX_use_certificate_ASN1(context_.native_handle(), sizeof(SSL_CERT_X509), SSL_CERT_X509);
        SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, context_.native_handle(), SSL_CERT_RSA, sizeof(SSL_CERT_RSA));
        SSL_CTX_set_verify_depth(context_.native_handle(), 1);

        signals_.add(SIGINT);
        signals_.add(SIGTERM);
        signals_.add(SIGBREAK);
#if defined(SIGQUIT)
        signals_.add(SIGQUIT);
#endif // defined(SIGQUIT)
        signals_.async_wait(boost::bind(&TcpServer::handle_stop, this));

        start_accept();
    }

private:
    tcp::acceptor acceptor_;
    asio::ssl::context context_;
    asio::signal_set signals_;
    TcpConnection::pointer new_ssl_connection;

    void start_accept(){
        new_ssl_connection.reset(new TcpConnection(acceptor_.get_io_service(), context_));
        acceptor_.async_accept( new_ssl_connection->socket(), 
                                    boost::bind(&TcpServer::handle_acceptSSL, this, asio::placeholders::error));
    }

    void handle_acceptSSL(const system::error_code& error){
	if(!acceptor_.is_open())
		return;

        if(!error)
            new_ssl_connection->start();

        start_accept();
    }
    void handle_stop(){
        acceptor_.close();
        printf("acceptor closed");
    }
};


The problem is that the cleanup code in the main function is never reached once io_service.run()[/code] is called. When I quit the console window he enters the handle_stop() (in most cases) but quits when calling acceptor_.close(); or printf(); with the return code(s)
1
2
3
4
The thread 'Win32 Thread' (0x1b5c) has exited with code 2 (0x2).
The thread 'Win32 Thread' (0x1be4) has exited with code -1073741510 (0xc000013a).
The thread 'Win32 Thread' (0x1170) has exited with code -1073741510 (0xc000013a).
The program '[2064] Avalon.exe: Native' has exited with code -1073741510 (0xc000013a).


I also tried fiddling around with TcpConnection being used as a shared pointer (as suggested at stackoverflow) but didn't get any different results.

Besides all that I tried out the boost::asio http examples 1 and 3 to see how it is done there but the same problem occurs (and I copied the example code 1:1).
So at this point I'm not even really sure if I'm doing something wrong or if the problem is something entirely different.

I would very much appreciate it if someone could give me some insight here since I couldn't really find any related problem.
Topic archived. No new replies allowed.