On Apr 30, 2010, at 11:48 AM, Pavel Pisa wrote: > Hello All, >
Hi, Thanks for the nice information. [...] > > You can easily check, if this is cause of your troubles > by running same code on 2.6.30+ kernel. > If you need correct behavior even on older kernels, > then it can be problematic. Basically you have to do > no I/O or changes related to any of FDs registered in epoll > if event count 0 is reported. I tested with the latest kernel and I get the same problem anyway, it's probably a bug within libevent. Best regards, Sebastian Sjoberg > > Best wishes, > > > Pavel Pisa > e-mail: p...@cmp.felk.cvut.cz > www: http://cmp.felk.cvut.cz/~pisa > university: http://dce.felk.cvut.cz/ > company: http://www.pikron.com/ > > > > On Thursday 29 April 2010 18:35:30 Nick Mathewson wrote: >> On Thu, Apr 29, 2010 at 5:19 AM, Sebastian Sjöberg >> >> <sebastian.sjob...@axis.com> wrote: >>> Hi, >>> >>> I've encountered a problem with openssl bufferevents where libevent >>> reports fd:s as writeable but no action is being taken. >> >> [...] >> >>> There is no problem when I'm connecting without tls so I think this is an >>> issue with openssl bufferevents and my guess is that somehow the write >>> events that openssl bufferevents sets up sometimes doesn't get removed or >>> disabled properly. >>> >>> Is this an issue that someone else has seen and does anyone have any >>> pointers on how to debug this problem? >> >> I haven't run into this myself yet, but the openssl code is relatively >> new, and probably has some bugs left. >> >> To clarify, it seems that the problem is that Libevent bufferevent >> openssl code never deletes the relevant read events, even though it >> isn't actually interested in reading? Or the problem is that epoll is >> returning immediately but not making any events active? >> >> If it's the first problem, I'd try adding debugging messages to the >> points in bufferevent_openssl that call event_add, event_del, and >> _bufferevent_add_event, along with debugging statements to display the >> return values of SSL_read and SSL_write, to see at what point we're >> supposed to be deleting the relevant read event but not really doing >> it. >> >> If it's the second problem, I'd start by testing whether stuff begins >> to work when you set the EVENT_NOEPOLL environment variable. If so, >> then the bug is probably with the epoll backend -- or at least, it >> requires the epoll backend to appear. To debug this, I'd add >> debugging messages to the loop in epoll_dispatch that calls >> evmap_io_active to tell me whenever it decided not to call >> evmap_io_active, and I'd have evmap_io_active tell me whenever it made >> 0 events become active. >> >> With any luck, the debugging output should help figure out exactly >> what's going wrong here. >> >> I'm afraid I'm about to be away from the internet for tomorrow and the >> weekend, so I won't be able to help much more until early next week. >> Good luck! >> >> yrs, >> -- >> Nick >> *********************************************************************** >> To unsubscribe, send an e-mail to majord...@freehaven.net with >> unsubscribe libevent-users in the body. > > *********************************************************************** > To unsubscribe, send an e-mail to majord...@freehaven.net with > unsubscribe libevent-users in the body. *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
