| Summary: | TAO/tests/Param_Test failed when ORBUseSharedProfile is set to 1 in ipv6 enabled builds | ||
|---|---|---|---|
| Product: | TAO | Reporter: | zhangw |
| Component: | ORB | Assignee: | Adam Mitz <mitza> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | mitza |
| Priority: | P3 | ||
| Version: | 1.5.1 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Bug Depends on: | 2173, 3695 | ||
| Bug Blocks: | |||
to reporter, can you add a new test for this issue This turns out to be a duplicate of 3695. But I was meaning to bring up this issue again anyway. Should we consider setting -ORBUseSharedProfile to default to 1 in the DOC distribution? The OCI distributions have been doing this for some time now. (In reply to comment #2) > This turns out to be a duplicate of 3695. But I was meaning to bring up this > issue again anyway. Should we consider setting -ORBUseSharedProfile to default > to 1 in the DOC distribution? The OCI distributions have been doing this for > some time now. See bug 2173, setting -ORBUseSharedProfile to 1 breaks RTCORBA in some areas. This was detected a long time ago, that is why we reverted that change in default on DOC group, not sure why OCI didn't do the same (In reply to comment #3) > (In reply to comment #2) > > This turns out to be a duplicate of 3695. But I was meaning to bring up this > > issue again anyway. Should we consider setting -ORBUseSharedProfile to default > > to 1 in the DOC distribution? The OCI distributions have been doing this for > > some time now. > > See bug 2173, setting -ORBUseSharedProfile to 1 breaks RTCORBA in some areas. > This was detected a long time ago, that is why we reverted that change in > default on DOC group, not sure why OCI didn't do the same > Phil's comment on 2173 says: > Now TAIA is only available when not using RTCORBA Which I think means that -ORBUseSharedProfile is effectively switched off by TAO when RTCORBA is in use. But I don't have much experience with RTCORBA so I'll leave that up to other to decide. I guess we should leave this bug open since it seems there are other IPv6-related issues beyond what 3695 fixed. It should probably be re-tested since it is 3 years old. We have TAO 1.6a builds that are both IPv6 and -ORBUseSharedProfile, and they are not failing Param_Test, but this may be related to a specific way the IPv6 interfaces are configured. |
Debian AMD64, Linux 2.6.8, gcc 4.0.3, ipv6 enabled. The Param_Test is failing when I passed "-ORBUseSharedProfile 1" to the server cmd line. Here are the steps to repeat it: ------8<------- $cd $TAO_ROOT/tests/Param_Test $./server -ORBUseSharedProfile 1 -o server.ior& $./client -f server.ior -i sii -t objref -n 5 -x Nil object references returned (client.cpp:134) client.cpp - run_sii_test: Invalid results in iteration 0 Nil object references returned (client.cpp:134) client.cpp - run_sii_test: Invalid results in iteration 1 Nil object references returned (client.cpp:134) client.cpp - run_sii_test: Invalid results in iteration 2 Nil object references returned (client.cpp:134) client.cpp - run_sii_test: Invalid results in iteration 3 Nil object references returned (client.cpp:134) client.cpp - run_sii_test: Invalid results in iteration 4 ERROR 5 faults in 5 calls *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= ********** Error running test_objref SII ********* (driver.cpp:48) driver.cpp - tests failed ------8<------- The above errors are due to the line 719 in the param_test_i.cpp: CORBA::Boolean equiv = myobj->_is_equivalent (o1 ACE_ENV_ARG_PARAMETER); myobj and o1 is not equivalent. The reason is as follows. If -ORBUseSharedProfile 1 is set, then multiple endpoints are composed in one profile. When the equivalency of the two profiles is tested, it compared each endpoint in the two profiles. The problem came up when ipv6 is enabled. Basically, it is the sin6_scope_id, e.g., %2 in the ipv6 link-local address that screwed up things. The endpoint in myobj has this "%2" showing in the ipv6 addr, but o1 does not. That's why the equivalency test has failed to pass. I noted in encode_endpoints() function, it takes out the sin6_scope_id. However when we use _this() to create the object reference, the sin6_scope_id is still there. There are at least two possible solutions to fix this: 1.) change the TAO_IIOP_Endpoint::is_equivalent(). In case of ipv6, don't ignore the sin6_scope_id part of the test. 2.) change TAO_IIOP_Acceptor::create_shared_profile(). When creating the profile, strip the sin6_scope_id from the hostname. Comments?