On Tue, Aug 21, 2012 at 8:02 PM, Hochhaus, Andrew
wrote:
> Hello,
>
> In libevent-2.0.19-stable, do_read can return 0 (stalled) when some
> progress has been made reading. This can occur, for example, when
> space[0].iov_len > 0 and the 2nd read attempt returns
> SSL_ERROR_WANT_READ. Then consider
On Wed, Aug 8, 2012 at 3:22 PM, Nick Mathewson 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 fi
On Wed, Aug 8, 2012 at 3:24 PM, Nick Mathewson wrote:
> On Mon, Aug 6, 2012 at 5:31 PM, Diwaker Gupta wrote:
> I don't believe that we defined whether setting the timeout to NULL
> will cancel any currently pending timeouts. That is, if the timeout
> has already fired, and
On Wed, Aug 8, 2012 at 11:52 AM, Nick Mathewson wrote:
> On Mon, Aug 6, 2012 at 2:42 PM, Matthieu Nottale
> wrote:
>> Hi.
>>
>> I'm experiencing a deadlock on 2.0.19 while calling bufferevent_free frome
>> thread A, while thread B is in event_base_dispatch.
>>
>
> Ouch. This is a known bug. Thi
There are a few libevent issues filed at
https://github.com/libevent/libevent/
And several more at
https://github.com/nmathewson/Libevent
This is very confusing for libevent users and the community at large.
It would be great if there was an unambiguous location for reporting
bugs and filing feat
On Thu, Mar 29, 2012 at 11:45 AM, Nick Mathewson wrote:
> On Thu, Mar 29, 2012 at 2:31 PM, Diwaker Gupta 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 valg
On Wed, Aug 8, 2012 at 11:52 AM, Nick Mathewson wrote:
> Ouch. This is a known bug. This fix is going to be hard. I wrote
> about it here:
> http://archives.seul.org/libevent/users/Feb-2012/msg00053.html
Does it make sense to move this to an actual bug on github so it is
easier for others to d
I've filed a bug with all details and sample code that demonstrates
the problem on Github:
https://github.com/libevent/libevent/issues/16
Nick: can you verify if my understand of the expected behavior is
correct. That is, if I set timeout to NULL, any existing timers should
get cancelled and no fu
http://www.wangafu.net/~nickm/libevent-book/ seems to be down
Not able to reach http://www.wangafu.net/~nickm/ either, so likely
something wrong with the host
cheers,
Diwaker
--
http://maginatics.com
***
To unsubscribe, send an e
> Maybe you can check if other events besides BEV_EVENT_ERROR are set?
> Like BEV_EVENT_EOF or BEV_EVENT_TIMEOUT? And are you sure the bufev
> ptr passed to bufferevent_write() is valid? Thats the most likely
> cause of generating segv's mostly.
I've already checked that EOF and TIMEOUT are not se
On Thu, Mar 29, 2012 at 11:45 AM, Nick Mathewson wrote:
> On Thu, Mar 29, 2012 at 2:31 PM, Diwaker Gupta wrote:
>> I'm using a filtered bufferevent to do SSL over another bufferevent.
>> Occasionally, my application crashes. Unfortunately, neither
>&g
I'm using a filtered bufferevent to do SSL over another bufferevent.
Occasionally, my application crashes. Unfortunately, neither
EVUTIL_SOCKET_ERROR nor bufferevent_get_openssl_error are useful.
The former says "Undefined error: 0" (via evutil_socket_error_to_string)
The latter gives "error:
On Wed, Mar 7, 2012 at 1:24 PM, Diwaker Gupta wrote:
> From
> http://www.wangafu.net/~nickm/libevent-book/Ref6a_advanced_bufferevents.html:
>
> "Note that when BEV_OPT_CLOSE_ON_FREE is set on a SSL bufferevent, a
> clean shutdown will not be performed on the SSL connec
>From
>http://www.wangafu.net/~nickm/libevent-book/Ref6a_advanced_bufferevents.html:
"Note that when BEV_OPT_CLOSE_ON_FREE is set on a SSL bufferevent, a
clean shutdown will not be performed on the SSL connection. This has
two problems: first, the connection will seem to have been "broken" by
the
> I haven't measured the performance difference, but I suspect it's
> real. The filtering case involves another layer of buffering,
> copying, and callbacks, and those typically matter. Then again, it
> could be that crypto dominates the performance. In either case,
> there's less machinery to g
I'm trying to figure out the best practice when it comes to OpenSSL
based bufferevents. For reference, I'm looking at the source code as
well as
http://www.wangafu.net/~nickm/libevent-book/Ref6a_advanced_bufferevents.html
As background, I have a fairly stable transport layer implemented
using reg
16 matches
Mail list logo
