Opened 9 years ago

#9817 new Bugs

Boost Asio + Visual Studio 2013 crashes without BOOST_ASIO_DISABLE_IOCP

Reported by: kasty.jose@… Owned by: chris_kohlhoff
Milestone: To Be Determined Component: asio
Version: Boost 1.55.0 Severity: Problem
Keywords: Cc:

Description

In a Visual Studio 2013 SP1 Project with 8 executables using boost asio, 1 of them crashes in a repetitive way, always at the same point. The problem is related to memory management and code generation when win_iocp_socket_service is used. For example the following code, under very special circumstances, may trigger the crash:

   tcp::iostream * sss = new tcp::iostream("mysite.com", "80");

I realized that everytime it crashes, win_iocp_io_service constructor is not called. Hence iocp_.handle is not initialized and is later used in CreateIoCompletionPort() containing garbage, this being the ultimate reason of the crash.

On the other hand, in the processes that work, the constructor is properly called, as it should always be. => Is there any known possibility for win_iocp_io_service constructor not being called? Is there anything like a default constructor that could be called instead?

  main()
  {
     tcp::iostream * sss = new tcp::iostream("mysite.com", "80");
  }

The code won't crash. But the following may do if MyClass instantiates boost::asio::io_service

  MyClass * myInstance = NULL;

  main()
  {
     if(myInstance) delete myInstance;
     tcp::iostream * sss = new tcp::iostream("mysite.com", "80");
  }

Don't expect to be able to reproduce it this way, as I said it's difficult to isolate because it probably is related to a bug in the compiler that only manifests in very special conditions that boost asio sometimes trigger. Simply moving lines of code may fix it.

The problem is not in memory management in our source code, that was my first thought, but all tests suggest it isn't. In addition, the code has been working for years with boost 1.45 and GCC 4.5. The only change was moving to Visual Studio 2013 and boost asio 1.55.

To corroborate, I was able to reproduce in a surrealistic way: just adding or commenting a line in dead code (code that can never be reached because it is placed after a return) would fix or make the application crash.

Finally I solved everything by defining BOOST_ASIO_DISABLE_IOCP. I didn't change a single line of code. No more crashes since then.

Change History (0)

Note: See TracTickets for help on using tickets.