[Xorp-hackers] fix assert in selector.cc

[Bruce Simpson]

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