[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] avoiding file descriptor collisions



On 12/09/11 11:26, William Ahern wrote:
A wild guess is that some code for connection Z (which predates A and B)
holds a stale descriptor value and is closing it. This is a common bug in
application code. Easiest way to avoid it is to never pass file descriptors
as values--except to low-level routines--but as references (say, as a member
of another object). When the descriptor is closed, set the descriptor value
to -1 so that there's no loaded gun lying around. It's the same concept as
setting a pointer to NULL after calling free. Technically it's not needed
but it pays divdends when trying to track down bugs.

An even wilder guess is that you have a pending callback which is firing
after some other callback which closed the descriptor, resulting in the
previous guess scenario. Juggling multiple concurrent callbacks for the same
resource can be difficult and is best avoided if possible.

I did ultimately find the cause of my problem. I was calling bufferevent_set_fd(-1) so that the bufferevent wouldn't close the file descriptor that evhttp was still using, but bufferevent_openssl doesn't actually set the file descriptor to -1, but rather just substitutes the file descriptor of the most recent event. I've updated my evhttp_connection_base_bufferevent_factory_new() patch to account for this (the patch actually got smaller and simpler). I attached the new patch to the sourceforge tracker at:

https://sourceforge.net/tracker/index.php?func=detail&aid=3458348&group_id=50884&atid=461322

Thanks,
Myk
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.