Ticket #8669 (closed Bugs: fixed)

Opened 2 years ago

Last modified 17 months ago

boost::asio::windows::random_access_handle is seriously broken

Reported by: ned14 Owned by: chris_kohlhoff
Milestone: To Be Determined Component: asio
Version: Boost Development Trunk Severity: Problem
Keywords: Cc:


This year a new library called Boost.AFIO extending Boost.ASIO with async file i/o was given funding for Google Summer of Code. This library has found some serious problems with Boost.ASIO's Windows IOCP boost::asio::windows::random_access_handle implementation:

  1. It appears to limit buffer sizes to 64Kb which corrupts output. This may be appropriate for non-random access e.g. network use (see, but it is a showstopper for file i/o. The windows::random_access_handle should have no such limitation.
  1. It appears to corrupt output when many buffers are passed, even when each of these is under 64Kb.
  1. It also doesn't appear to like doing scatter/gather file i/o from multiple threads.

You will note that the POSIX (Linux) implementation doesn't have any of these problems (see This is something wrong with the Windows IOCP implementation in Boost.ASIO.

To illustrate the problem, I have created a special branch for this bug report at If you examine you'll see that I've created a macro BOOST_ASIO_BUG_WORKAROUND which when defined gets the torture test to pass. If you run through main.cpp looking for BOOST_ASIO_BUG_WORKAROUND you'll see the changes I had to make to get things working - these are a good indicator of what's going wrong in Boost.ASIO I think.

To run just the failing unit test which exhibits the problem, use "x64/Debug/tests async_io/torture". You'll need the experimental VS2012 Nov 2012 CTP compiler supporting variadic templates to compile the code successfully in Visual Studio 2012.

My thanks in advance for your time.



Change History

comment:1 Changed 2 years ago by ned14

Sorry I was unclear with problem no 2: I suspect Boost.ASIO isn't incrementing in an atomic fashion (or at all) the Offset member of the OVERLAPPED structure during multi-buffer reads and writes. With sockets and pipes of course this would never have been necessary.


comment:2 Changed 2 years ago by ned14

Bug #8935 may be related.

comment:3 Changed 17 months ago by chris_kohlhoff

  • Status changed from new to closed
  • Resolution set to fixed
  • Severity changed from Showstopper to Problem

In r85750, added a note to clarify that programs must not issue concurrent async_write_at operations for overlapping regions. Included in boost 1.55.


Add a comment

Modify Ticket

Change Properties
<Author field>
as closed
The resolution will be deleted. Next status will be 'reopened'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.