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

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Wed, Aug 8, 2012 at 3:24 PM, Diwaker Gupta <diwaker@xxxxxxxxxxxxxx> wrote:
> 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:

At what point in this do you get the crashes you were mentioning
before?  Could you please include a stack trace, please?

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

If it's an error reported on the underlying BIO, have a look at the
BIO_-implementation code in bufferevent_openssl.c -- that would be the
thing reporting implementing the underlying bufferevent.  Those
functions have names like bio_bufferevent_*().  Maybe adding some
logging code to the places where they are about to report errors would
help figure out where the error is coming from?

In any case, though, an error from an underlying BIO is no excuse for crashing.

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