Re: [Libevent-users] Debugging bufferevent_openssl (filtered)

[Diwaker Gupta <diwaker@xxxxxxxxxxxxxx>]

On Thu, Mar 29, 2012 at 11:45 AM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> On Thu, Mar 29, 2012 at 2:31 PM, Diwaker Gupta <diwaker@xxxxxxxxxxxxxx> wrote:
> The most useful thing here would probably be a stack trace with as
> much debugging information as possible.  Additionally, running under a
> debugging tool like valgrind (or the local equivalent on your
> platform) might give you useful information.

Reviving this thread as I'm still running into spurious SSL failures
when using a filtered bufferevent. I have stack traces but I found it
a lot more useful to just modify the libevent code to add more debug
logs and use those to figure out what's going on. Here's what I
observe:

* during some SSL operation, we call into conn_closed (I'll update the
thread later with exactly which op, but it's likely do_read)
* within conn_closed, errcode is SSL_ERROR_SYSCALL, ret is -1 and errno is 0

Here's what the SSL man page says about the SYSCALL error:

SSL_ERROR_SYSCALL
Some I/O error occurred.  The OpenSSL error queue may contain more
information on the error.  If the error queue is empty (i.e.
ERR_get_error() returns 0), ret can be used to find out more about the
error: If ret == 0, an EOF was observed that violates the protocol.
If ret == -1, the underlying BIO reported an I/O error (for socket I/O
on Unix systems, consult errno for details).

Since ret is -1 and errno is 0, I'm not sure where to go next. In
particular, I'm not sure how to isolate this to libevent (vs. an
OpenSSL issue).

Note that this happens non-deterministically and typically under high
load. I'm on Ubuntu 12.04 using libevent 2.0.19 and OpenSSL 1.0.0e

Diwaker
-- 
http://maginatics.com
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.