On Jun 26, 2012 3:08 PM, "Zack Weinberg" <za...@panix.com> wrote: > > On Tue, Jun 26, 2012 at 8:41 AM, Nick Mathewson <ni...@freehaven.net> 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
