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

[Ben Greear]

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