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

[Diwaker Gupta <diwaker@xxxxxxxxxxxxxx>]

On Wed, Aug 8, 2012 at 3:22 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
>> 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?

Sorry, I should have clarified: I'm not seeing any *crashes* due to
libevent. I am seeing spurious SSL failures though -- spurious, in the
sense that I get the SYSCALL error but ret is -1 and errno returns 0.
Here's a stack trace when that happens:

#0  0x00007fff8e4dace2 in __pthread_kill ()
#1  0x00007fff867957d2 in pthread_kill ()
#2  0x00007fff86786a7a in abort ()
#3  0x00000001007ca309 in conn_closed (bev_ssl=<value temporarily
unavailable, due to optimizations>, errcode=<value temporarily
unavailable, due to optimizations>, ret=<value temporarily
unavailable, due to optimizations>) at bufferevent_openssl.c:504
#4  0x00000001007ca5cf in do_read (bev_ssl=0x101d262e0, n_to_read=0)
at bufferevent_openssl.c:614
#5  0x00000001007cabec in consider_reading (bev_ssl=0x101d262e0) at
bufferevent_openssl.c:779
#6  0x00000001007c11ef in bufferevent_run_deferred_callbacks_unlocked
() at TAsyncChannel.cpp:834
#7  0x00000001007b9a75 in event_base_loop () at TAsyncChannel.cpp:834

Disregard the first 3 frames -- I added the abort as a cheap hack to
get a quick stack trace.

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

The SYSCALL error is always happening within do_read. I'm now adding
some debug logs to the bio_* routines; will update this thread when I
find some more. I do see though that all of the bio_* routines return
0, 1 or -1 (except read, which can return the number of bytes read).
Presumably the OpenSSL library is the one that generates the SYSCALL
error based on the return codes?

In the meantime, any other ideas will be much appreciated.

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



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