id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
9817	Boost Asio + Visual Studio 2013 crashes without BOOST_ASIO_DISABLE_IOCP	kasty.jose@…	chris_kohlhoff	"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.

"	Bugs	new	To Be Determined	asio	Boost 1.55.0	Problem