Hrrm.. this is interesting. So you're saying do_fill_input_buffer is not returning an error status. This means the problem is inside the packet decoding.
I don't want to jump the gun and say this is a server issue – as I'm quite sure the server has traveled this path before.
So you're saying you get the error when io->error == EWOULDBLOCK?
I'll need to poke around parse_single and see what might be failing. There might also be possible reentrancy issues as well..
Basically, the callback is invoked from do_parse_single; but the buffer is only "cleaned up" after the callback returns.
This means we might be doing weird things with the buffers..
Just wondering (and I'm gonna try and replicate this tomorrow.. now that I might have a bit of a better idea regarding what's happening here..):
Are you issuing any batched requests (i.e. gets where you are passing more than a single command to libcouchbase) before this?
Are any of your results not found?
Does this only occur with get commands, or does this happen with sets as well
Basically there is special handling when we receive responses for batched gets.
It would be awesome if you can see where parse_single is returning -1 (which it now seems it is..)
It also seems that in all cases where that function returns -1, the "global" error handler (i.e. set_error_callback) should tell you something as well.