[Xorp-hackers] valgrind: selector.cc: Reading free'd memory

Ben Greear greearb at candelatech.com
Tue Sep 29 19:18:20 PDT 2009


On 09/29/2009 05:45 PM, Ben Greear wrote:
> Looks like we are running stale node objects that have since
> been deleted by the resizing of the _selector entries.
>
> This is from my code tree, so it's possible it's something I added,
> but I don't think it is...
>
> I'm going to work on fixing this, but if someone has any quick ideas, feel free
> to let me know!

This one is nasty.  Here's the work-around fix:

Most of the attached patch is debugging logic, and you can skip all of that
if you want.  The thing that actually 'fixes' it is this:

selector.cc:
@@ -199,9 +228,18 @@ SelectorList::Node::is_empty()
  // ----------------------------------------------------------------------------
  // SelectorList implementation

+
+// NOTE:  It is possible for callbacks to add an event, that that event can
+// cause the selector_entries to be resized.  See:  add_ioevent_cb
+// This in turn deletes the old memory in the vector.  This this causes
+// Node::run_hooks to be accessing deleted memory (ie, 'this' was deleted during
+// the call to dispatch().
+// Seems like a lot of pain to fix this right, so in the meantime, will pre-allocate
+// logs of space in the selector_entries vector in hopes we do not have to resize.
  SelectorList::SelectorList(ClockBase *clock)
      : _clock(clock), _observer(NULL), _testfds_n(0), _last_served_fd(-1),
-      _last_served_sel(-1), _maxfd(0), _descriptor_count(0), _is_debug(false)
+      _last_served_sel(-1), _selector_entries(1024),
+      _maxfd(0), _descriptor_count(0), _is_debug(false)
  {
      static_assert(SEL_RD == (1 << SEL_RD_IDX) && SEL_WR == (1 << SEL_WR_IDX)
  		  && SEL_EX == (1 << SEL_EX_IDX) && SEL_MAX_IDX == 3);


Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: selector_xorp_crash.patch
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090929/8f524e85/attachment.ksh 


More information about the Xorp-hackers mailing list