[Libevent-users] Request for input on pending bufferevent_openssl patch.

[Mark Ellzey <mthomas@xxxxxxxxxx>]

Greetings all,

I have recently come across a pretty nasty issue using the 
bufferevent_openssl API where my read callback would be executed more
than once, even if I had disabled reading. This is an edge-case bug which 
can be triggered under the following conditions:

01. bufferevent_enable(ssl_bev, EV_READ);
02. be_openssl_readcb()
03. consider_reading()
04. do_read()
05. _bufferevent_run_readcb()
06. my readcb is executed and it then calls bufferevent_disable(ssl_bev, EV_READ)
07. returns back to do_read()
08. if SSL_pending() returns > 0, do_read() is called again.
09. do_read()
10. _bufferevent_run_readcb()
11. my readcb is executed again. The expected behaviour here has now
    been violated. Once bufferevent_disable(..., EV_READ) is called, the
    users readcb shouldn't be executed until enabled again. 

I consider the conditions above one of the reasons openssl bufferevents
can be quite unstable if not being run as DEFERRED.

Nick agrees this is a fairly nasty bug, and I have attempted to fix the
problem with this patch:
https://github.com/ellzey/Libevent/commit/5cceae1ca32551312a86df7b6fa2576fd0a71ee4

But we also both agree that it would be good to have some users who rely
on openssl bufferevents extensively to test this, making sure things still 
work as expected.

This is partly because _bufferevent_run_readcb() calls have been moved around
into other functions, and also because when we addressed other nasty ssl
bugs in prior releases, we introduced new ones (twice, if I recall). I
(we) would like to avoid this from happening a third time.

So, if people could so kindly test this patch, I'll buy you a beer of
your choice.

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