> -Original Message-
> From: nick.a.mathew...@gmail.com [mailto:nick.a.mathew...@gmail.com] On
> Behalf Of Nick Mathewson
> Sent: Thursday, November 04, 2010 12:20 PM
> To: Gilad Benjamini
> Subject: Re: [Libevent-users] Read failures on Unix socket
>
> On Thu, Nov 4, 2010 at 2:09 PM, Gila
On Thu, Nov 4, 2010 at 9:10 PM, Nick Mathewson wrote:
> Assuming that it now crashes in a different place from where it used
> to crash -- that is, at ASSERT_VALID_REQUEST in evdns_cancel, I've got
> an updated patch, attached below. Third time is maybe the charm.
Yeah, it seems to work now with
On Thu, Nov 4, 2010 at 11:49 AM, Kelly Brock wrote:
[...]
> Got the fix. Fricken IOCP strangness bites again. You just have to
> insert a call to:
>
> int err = setsockopt( fd,
> SOL_SOCKET,
> SO_UPDATE_ACCEPT_CONTEXT,
> (char *)&listen
> Hm. Looking at the epoll output in the "nonblocking" case, it doesn't
> look like Libevent is doing anything weird here: epoll_wait() is
> honest-to-goodness saying "Okay to read on fd 15"...
>
> 23:08:05 epoll_wait(4, {{EPOLLIN, {u32=15, u64=15}}}, 32, 0) = 1
>
> ...but the recvfrom is saying
Hi Nick,
> >> So, I've managed to poke around just a little since sending the
> >> example code and not really found anything interesting as of yet but
> had
> >> an
> >> evil thought. I started wondering about the "shutdown" function being
> >> unreliable with IOCP from your information.
On Wed, Nov 3, 2010 at 10:44 PM, Denis Bilenko wrote:
> On Thu, Nov 4, 2010 at 1:24 AM, Nick Mathewson wrote:
>>> You free req->handle and then access it.
>>
>> Ugh. What if we move "req->handle->current_req =NULL" to *above* that "if" ?
>
> Still crashes.
Assuming that it now crashes in a diff
Hello,
I made a daemon that receives data from a socket, data is read from
callback (readcb) :
> bufferevent_setcb(bev, readcb, NULL, eventcb, conndata);
then it is given to a thread (because the treatment can be long). Then
this is the thread that writes the result of the treatment on the sock
