NFD

This condition could happen if closeSocket is invoked before handleSend.

Hmm... That should be "impossible". At least I have assumed that after m_socket->close(error); handleSend should be called with some error code (boost::system::errc::operation_canceled) and not get asserted...

Should I simply change assert to a condition and that would fix the problem?

Make a test case to confirm or reject the hypothesis that handleSend would be called with error code if closeSocket is invoked.
Don't change anything without finding the reason.

Alex Afanasyev wrote:

To avoid problems, queue is cleaned after all pending callbacks are fired. handleSend will not assert, as the scheduled callback, if any, will immediately return with error code = invalid handler.

I'm not sure I understand the last part.

handleSend no longer asserts because the queue is not cleared immediately in closeSocket, but only after all pending callbacks have been executed. Therefore handleSend will try to schedule the next async_write (assuming more blocks are in the queue) on a closed socket and fail. Is this correct? What is this "invalid handler" thing?

Ok. Let me give a sequence what I was observing:

• normal handleSend that schedules async_write with handleSend callback
• async_receive callback calls closeSocket, socket close, shutdown

• normal handleSend that schedules async_write with handleSend callback

  This is abnormal and was not expected

  At this point, socket is no longer valid, so the scheduled async_write will fail

• queue is getting cleaned somewhere here

• handleSend with error code 9 (= invalid handler or something like that)

This happens after applying your patch?

Yes. These after the patch. Before the patch, queue cleanup happens at step 2 and step 3 causes assertion fault.

Ok makes sense. Error code 9 is actually EBADF "bad file descriptor", which again makes sense since the fd becomes invalid when the socket is closed.

Boost.Asio problem should be reported to Boost, and Boost ticket should be referenced here.

It's unsafe to send into a bad file descriptor.
Kernel can reuse a file descriptor after it's closed.
If something is sent into a closed and then reused file descriptor, it may go into another socket (and cause a decode error in the app).

Junxiao Shi wrote:

It's unsafe to send into a bad file descriptor. Kernel can reuse a file descriptor after it's closed.

This is true, although it's unlikely to happen. Anyway, I've submitted an alternative solution as patch set 5 at http://gerrit.named-data.net/1211 which does not suffer from this issue.