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

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

On Apr 29, 2010, at 6:35 PM, 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?

It seems to be the latter.

> 
> 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.

I've added stack backtraces in event_(del|add)_internal, mostly to figure out where they get called from in the openssl bufferevent code but I haven't yet been able to interpret them completely but they might shed some light on what's going on.

> 
> 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.

Cheers, I haven't yet been able to reproduce it when disabling epoll.

I've started to debug the evmap_io_active calls and after a while there are a no events being activated as you said so I guess at some point the there's a mismatch between what's in epoll and in the event map.

> 
> 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!

Thanks, I won't be looking at this until after the weekend either.

Best regards,
Sebastian Sjoberg

> 
> 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.