On Jun 26, 2012 3:08 PM, "Zack Weinberg" <zackw@xxxxxxxxx> wrote:
>
> On Tue, Jun 26, 2012 at 8:41 AM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> > It will work only so long as there are no "deferred callbacks" queued.
>
> By "deferred callbacks" do you mean the implementation of
> BEV_OPT_DEFER_CALLBACKS, or something else? This program doesn't use
> that, although maybe it should (I'm not at all clear on what that's
> supposed to be for).
Yes, that. They were a feature introduced in 2.0 to deal with crazy priority inversions and callback loops in some of the code paths. For example, without them it was pretty easy for a bufferevent_pair to blow the stack by having one of the pair's callbacks cause another one to get invoked.
I believe at least one of the bufferevent types (pair) will automatically run with deferred callbacks; you should check that you're not using a type with that property.
> > Well, the behavior you describe shouldn't actually be happening:
> > Libevent should not call any callbacks on *foo* after you have called
> > the appropriate *foo*_del() or *foo*_free() function.
> >
> > If you can come up with an example of when the undesirable behavior
> > occurs -- ideally with a minimal test case to reproduce -- we might be
> > able to track it down.
>
> Unfortunately it only happens intermittently, under conditions of
> extreme packet loss. I'd like to improve my test harness to let me
> produce such conditions in the lab, as it were, but I've got
> inconvenient deadlines...
>
> By code inspection, in 2.0 (didn't check 2.1), I can see a way for it
> to happen if BEV_OPT_DEFER_CALLBACKS *is* used: both variants of
> bufferevent_run_deferred_callbacks potentially call several callbacks
> on the same bufferevent without checking in between to see if one of
> the callbacks has deallocated the bufferevent. (You've got some sort
> of reference count in there, so that may be safe as far as the 'struct
> bufferevent' itself, but there is no such protection for the callback
> data.)
Hm. Now *that's* a bug. Gotta think about the right fix there: a minimal fix would probably be better for 2.0, though my preferred strategy for 2.1 would probably be more invasive. Any thoughts or patches would be welcome.
> Maybe there is a similar control flow issue in the non-DEFER_CALLBACKS
> case but if so it is not obvious to me. (I *thought* I remembered
> seeing a way for the socket bufferevent_readcb to call both the read
> and the event callbacks, in the same fashion, but it looks like I
> misread it.)
To narrow this down, what bufferevent types and other pieces of libevent are you using? And have you seen these issues only with bufferevent callbacks, or others too?
--
Nick