Ben, Thanks for your patch. Can you clarify how/when this condition is triggered, with a full backtrace please?
It would be very helpful to get a root cause analysis on this condition you are observing, before a 1.7-RC. Ben Greear wrote: > It's possible this is caused by some of my own patches, but I think it's > a logic > bug: If the only fd ISSET has infinite priority, it will not be chosen and > will hit the assert at the bottom of the method. XorpTask::PRIORITY_INFINITY seems to mean 'this task has infinitely low priority', and therefore should not be run. Using KScope, I do not see any place in the code where a XorpTask is being explicitly instantiated with PRIORITY_INFINITY. Perhaps the bug lies elsewhere, and the assertion is triggered for some other reason? It is likely that the EventLoop/SelectorList code would be completely replaced by the boost::asio::io_service reactor class when Boost is introduced. > For me, simply calling: xorpsh > when no rtr-mgrs are running causes the crash. > I was unable to reproduce this condition in FreeBSD 7.2-STABLE, g++ 4.2.1, with the latest SVN trunk. The xorpsh simply exits after the timeout as expected, with the usual error messages: %%% anglepoise# /usr/local/xorp/bin/xorpsh Waiting for xorp_rtrmgr... [ 2009/09/01 15:21:50 ERROR xorpsh:26879 RTRMGR +96 rtrmgr/xorpsh_main.cc wait_for_xrl_router_ready ] XrlRouter failed. No Finder? [ 2009/09/01 15:21:50 ERROR xorpsh:26879 RTRMGR +905 rtrmgr/xorpsh_main.cc main ] xorpsh exiting due to an init error: Failed to connect to the router manager %%% This is using a shared library build, although that should not make any difference. thanks, BMS _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
