We regularly call the function PCTimeoutUart::wait( iseSize_t len, uint32 timeoutInMS ) which wraps the calls to the boost asio libraries.
This creates a deadline_timer, and binds it to our timeout callback (PCTimeoutUart::finishedTimer) It also calls async_read_some on the boost::asio::serial_port object m_port to read the required length, and binds that to the PCTimeoutUart::finishedRead callback.
We call the runone() function on m_io, which is declared in the header as a boost::asio::io_service and has been passed to both the timer and serial port's constructors.
We continually call this in a loop until either m_timedOut has been set by the asynchronous call back to PCTimeoutUart::finishedTimer or m_finishedRead has been set via the call back to PCTimeoutUart::finishedRead
Normally, this works well. However, there are certain scenarios when it fails to write anything to the buffer, despite the fact that finishedRead() is called with error = 0 and the correct length .
I don't know whether it's related or not (most likely not), but it seems that the following code is dangerous, as you delete the buffer without waiting for the async read completion. You assume that after you call cancel(), the buffer won't be used anymore by the async operation -- which is not obvious, imho. if( m_timedOut ) { m_port.cancel(); delete[] buffer; return false; }