[Xorp-hackers] Why use the home-grown heap.cc?

Orion Hodson oho at acm.org
Sat Mar 1 00:04:13 PST 2008


It was something that an earlier contributor had on the shelf that  
matched requirements at the time and was AFAIR well tested in previous  
scenarios. The existing heap allows popping an arbitrary item in the  
heap by design, which is useful when the heap is a container for  
timers that may be unscheduled.

Nothing is set in stone so if there is a patch to STL-ize it and that  
patch passes regressions and is demonstrably better then it'd likely  
be taken up.

- Orion

On Feb 29, 2008, at 11:16 PM, Ben Greear wrote:

> While testing the latest xorp (plus my patches, which certainly  
> could be
> the cause),
> I ran into the assert below.  Before I dig into this farther, I am
> curious if there is a good
> reason we are using a home-grown heap class as opposed to something  
> from
> the STL?
>
> Loaded symbols for /lib/libnss_files.so.2
> Core was generated by `xorp_rtrmgr -p 20002 -b vr_conf/xorp- 
> vr10002.conf'.
> Program terminated with signal 6, Aborted.
> #0  0xb7f74410 in __kernel_vsyscall ()
> (gdb) bt
> #0  0xb7f74410 in __kernel_vsyscall ()
> #1  0x0056f690 in raise () from /lib/libc.so.6
> #2  0x00570f91 in abort () from /lib/libc.so.6
> #3  0x0817f119 in xlog_fatal (module_name=0x820c3b9 "LIBXORP",
> where=0xbfbfd068 "heap.cc:171 pop_obj",
>    fmt=0x820c484 "-- heap_extract, father %d out of bound 0..%d") at
> xlog.c:435
> #4  0x081a478c in Heap::pop_obj (this=0x84cb478, obj=0x84cf918) at
> heap.cc:170
> #5  0x081a0159 in TimerList::unschedule_node (this=0xbfc010cc,
> n=0x84cf918) at timer.cc:592
> #6  0x081a01c8 in TimerNode::unschedule (this=0x84cf918) at timer.cc: 
> 119
> #7  0x081a032e in ~TimerNode (this=0x84cf918) at timer.cc:74
> #8  0x081a2984 in ~PeriodicTimerNode2 (this=0x84cf918) at timer.cc:188
> #9  0x0819f2b0 in TimerNode::release_ref (this=0x84cf918) at  
> timer.cc:87
> #10 0x08069322 in ~XorpTimer (this=0x84c9df0) at timer.hh:535
> #11 0x08110cd7 in ~Finder (this=0x84c9d6c) at finder.cc:360
> #12 0x080f83eb in ~FinderServer (this=0x84c9d68) at finder_server.cc: 
> 82
> #13 0x08067c5e in Rtrmgr::run (this=0xbfc01438) at main_rtrmgr.cc:350
> #14 0x08068353 in main (argc=5, argv=0xbfc01544) at main_rtrmgr.cc:500
> (gdb) frame 4
> #4  0x081a478c in Heap::pop_obj (this=0x84cb478, obj=0x84cf918) at
> heap.cc:170
> 170     heap.cc: No such file or directory.
>        in heap.cc
> (gdb) print father
> $1 = 3
> (gdb) print _elements
> $2 = 1
> (gdb)
>
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers



More information about the Xorp-hackers mailing list