Bruce Simpson wrote: > > I've tested this briefly with the current SVN tree, just by running > a xorp_finder, call_xrl, and a xorp_rib. This exercises the reentrancy > of the XRL client stubs, because the Finder Client is instantiated > once for every XrlRouter. The RIB uses libfeaclient, which > instantiates its *own* XrlRouter instance (yes, you can have more than > one per process...) for getting interface updates from the FEA.
Anyway, back to this incremental change. For testing, 3 shells: 1. Start the Finder (tedious, LD_LIBRARY_PATH needed if doing it from the source tree, which I don't recommend normally):- %%% anglepoise:~/svn/xorp/xorp % !81 env LD_LIBRARY_PATH=obj/x86_64-unknown-freebsd7.2/libxipc:obj/x86_64-unknown-freebsd7.2/libcomm:obj/x86_64-unknown-freebsd7.2/libxorp ./obj/x86_64-unknown-freebsd7.2/libxipc/xorp_finder -v Finder \ %%% 2. Start the RIB: %%% anglepoise:~/svn/xorp/xorp % env LD_LIBRARY_PATH=obj/x86_64-unknown-freebsd7.2/libxipc:obj/x86_64-unknown-freebsd7.2/libcomm:obj/x86_64-unknown-freebsd7.2/libxorp:obj/x86_64-unknown-freebsd7.2/rib:obj/x86_64-unknown-freebsd7.2/libfeaclient:obj/x86_64-unknown-freebsd7.2/xrl/interfaces:obj/x86_64-unknown-freebsd7.2/xrl/targets:obj/x86_64-unknown-freebsd7.2/policy/backend:obj/x86_64-unknown-freebsd7.2/policy/common:obj/x86_64-unknown-freebsd7.2/libproto ./obj/x86_64-unknown-freebsd7.2/rib/xorp_rib %%% 2b. You should see the Finder complain about RIB asking where the non-existent FEA is in the first shell: %%% [ 2009/11/08 14:07:31 WARNING xorp_finder XrlFinderTarget ] Handling method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed Target "fea" does not exist or is not enabled. %%% 3. Use call_xrl to verify the RIB registered OK with the Finder, by asking for all XRL targets to be dumped out: %%% anglepoise:~/svn/xorp/xorp % !32 env LD_LIBRARY_PATH=obj/x86_64-unknown-freebsd7.2/libxipc:obj/x86_64-unknown-freebsd7.2/libcomm:obj/x86_64-unknown-freebsd7.2/libxorp ./obj/x86_64-unknown-freebsd7.2/libxipc/call_xrl finder://finder/finder/0.2/get_xrl_targets target_names:list=:[email protected],:txt=finder,:[email protected],:[email protected] %%% As you can see, the RIB came up OK in this case. Profiling with the FreeBSD valgrind snapshot revealed that the "still reachable loss records" for the send*() methods in the XIF client stubs had indeed gone away, a desired result -- it's good to fix memory leaks. I'll hold off on committing for now, though. It would be good to know if changing the Xrl allocation in this way helps the situation with the race you saw... _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
