Re: [Libevent-users] 100% cpu utilization with openssl bufferevent.

[Sebastian Sjöberg <Sebastian.Sjoberg@xxxxxxxx>]

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:     pisa@xxxxxxxxxxxxxxxx
>    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.Sjoberg@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxx with
>> unsubscribe libevent-users    in the body.
> 
> ***********************************************************************
> To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.

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