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.
***
To unsubscribe, send an e-mail
Hi Nick,
> >> This certainly seems like an evil stupid thing IOCP could be
> doing
> >> here. :(
> >
> > Nope, wasn't this. Can't even get EOF using the
> WSASendDisconnect
> > calls, something is definitely wrong at a lower level. Will dig into it
> > more as I find time.
>
> Were
On Wed, Nov 3, 2010 at 8:45 PM, Kelly Brock wrote:
> Hi again,
>
>> 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
>> u
Hi again,
> 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. I can't say for
Hi Nick,
Any luck on this?
> > > Anywhere, here is a quick and dirty testbed for the problem.
> > >
> > > http://pastebin.com/QF4N2DEw
> > >
> > > If you leave "USE_IOCP" set to 0 everything shuts down
> correctly.
> > > If you turn that flag on though, the EOF's are never s
On Wed, Nov 3, 2010 at 2:35 PM, Denis Bilenko wrote:
> On Wed, Nov 3, 2010 at 10:38 PM, Nick Mathewson wrote:
>>> Probably the right answer here is to add a reference count to the
>>> request, and not actually free it until the reference count hits zero.
>>
>> Actually, we can go even simpler. H
On Wed, Nov 3, 2010 at 10:38 PM, Nick Mathewson wrote:
>> Probably the right answer here is to add a reference count to the
>> request, and not actually free it until the reference count hits zero.
>
> Actually, we can go even simpler. Here's the patch I've got in mind.
>
> There may be better wa
On Wed, Nov 3, 2010 at 11:33 AM, Nick Mathewson wrote:
> On Wed, Nov 3, 2010 at 7:41 AM, Denis Bilenko wrote:
>> So what happens here, is that eventually reply_handle is called, which calls
>>
>> reply_schedule_callback(req, ttl, 0, reply); in evdns.c:872
>> and then
>> request_finished(req, &REQ
On Tue, Nov 2, 2010 at 2:56 PM, Gilad Benjamini wrote:
> I have a simple piece of code which used to work with libevent 1.4 and now
> fails with 2.x
Same drill as last time: I tried hacking up example code to match your
description, and can't reproduce the behavior you're seeing, so
there's proba
On Wed, Nov 3, 2010 at 7:41 AM, Denis Bilenko wrote:
> So what happens here, is that eventually reply_handle is called, which calls
>
> reply_schedule_callback(req, ttl, 0, reply); in evdns.c:872
> and then
> request_finished(req, &REQ_HEAD(req->base, req->trans_id), 1); in evdns.c:876
> which cal
On Wed, Nov 3, 2010 at 8:07 AM, Kevin Bowling wrote:
> Hello,
>
> Is there a recommended means of testing for libevent2 from within autoconf?
> I'm wondering if anybody else has written an m4 macro that can check for an
> adequate system copy, look in an argument passed to configure, or build a
>
Hello,
Is there a recommended means of testing for libevent2 from within autoconf?
I'm wondering if anybody else has written an m4 macro that can check for an
adequate system copy, look in an argument passed to configure, or build a
bundled version (since many distros are on 1.x).
Regards,
Kevin
So what happens here, is that eventually reply_handle is called, which calls
reply_schedule_callback(req, ttl, 0, reply); in evdns.c:872
and then
request_finished(req, &REQ_HEAD(req->base, req->trans_id), 1); in evdns.c:876
which calls mm_free(req->handle)
When I call cancel I pass this freed han
13 matches
Mail list logo
