Nick, that was not the very bottom of it :)
I got email from Alexander Drozdov with a note that this behavior only happens when IP_RECVERR is set on the socket. Well, that's true: without this flag, there is not such effect. Why I am setting this flag is another story. But, supposedly, when a person is setting this flag, he/she must understand what the person is doing.
Still, it would be probably nice-to-mention in the documentation, for Linux only. Something like that: "if a Linux socket is having an error stored in the message queue, then it will result in a "read" callback with empty input data. This callback will be poppoing up indefinitely until the error queue got cleaned in the application code, by using recvmsg with MSG_ERRQUEUE flag."
May be future UDP-based bufferevents can somehow provide a higher interface to that.
By the way, I have, to some extend, a similar situation with TCP sockets. When I have a listening socket, and the number of socket exceeds the system limit, then I am getting messages from the listening libevent callback like:
[warn] Error from accept() call: Too many open files
Basically, the system just has to wait till the socket number decreases. Reporting million errors to the stderr at this moment, from my point of view, rather pointless. Understandably, accept() has problems in the too many open files condition, but I am not sure that it has to be reported to stderr so many times.