On Mon, Dec 19, 2011 at 5:34 PM, Haseeb Abdul Qadir <hase...@jumpdesktop.com> wrote: > <resending as per Nick's request> Thanks for resending this on the mailing list.
> SSL_pending() ends up returning 0 in some cases even when the underlying BE's > input buffer has data left to consume This is exactly the condition I was afraid of back when 2aa036f was being discussed. I was never able to come up with a concrete scenario, but it seemed conceivable. Note that I was using an OpenSSL bev layered directly on top of BIO_socket, not looping back over an underlying bev. OTOH, if SSL_pending can return 0 with bytes queued in the evbuffer, then these bytes could just as well be queued in the kernel, when layering over BIO_socket. So it might be possible to reproduce the condition with bev_ssl-over-BIO_socket too. > I've created the patch below and it seems to fix the issue on my end. > https://github.com/haseebq/libevent/commit/c58d9d8d437d122a8b67d42a6126d81699ec6914 I'm a bit confused by the patch - n_to_read is a number of cleartext bytes to be read from SSL, right? You're setting it from evbuffer_get_length, which is a number of encrypted bytes on the underlying bev (below SSL). > Ps - I haven't tried to reproduce this bug in a stand alone project yet. Would you be able to provide a repro, or at least some more in-depth description of the conditions that prompted the issue to surface? *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
