On Thu, Mar 29, 2012 at 11:45 AM, Nick Mathewson <ni...@freehaven.net> wrote: > On Thu, Mar 29, 2012 at 2:31 PM, Diwaker Gupta <diwa...@maginatics.com> 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 majord...@freehaven.net with unsubscribe libevent-users in the body.
