| Summary: | Transport::IIOP::Current segmentation fault when using SSLIOP | ||
|---|---|---|---|
| Product: | TAO | Reporter: | Ivan Vitjuk <virtus> |
| Component: | SSLIOP Pluggable Protocol | Assignee: | Iliyan Jeliazkov <iliyan> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | totten_s, virtus |
| Priority: | P3 | ||
| Version: | 1.6.3 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Attachments: |
Configuration files for server and client.
Patch that changes IIOP_Current_Impl.cpp to handle only SSLIOP connections. |
||
I've found exact reason of this bug. On the line
TAO/tao/TransportCurrent/IIOP_Current_Impl.cpp:39 there is a dynamic
downcast of TAO_Connection_Handler to TAO_IIOP_Connection_Handler:
return dynamic_cast <TAO_IIOP_Connection_Handler*> (ch);
which fails in case of SSLIOP connection because in this case child of
TAO_Connection_Handler is not TAO_IIOP_Connection_Handler but
TAO::SSLIOP::Connection_Handler. To prove this I've made trivial
patch that handles correctly _only_ SSLIOP connections, which is in
attachment.
Created attachment 947 [details]
Patch that changes IIOP_Current_Impl.cpp to handle only SSLIOP connections.
understand the problem but the patch can't be used. including ssliop from here is not an option. I think that at the end you shouldn't be able to get an IIOP current because you are not using IIOP, at the end an SSLIOP current has to be added which then can be retrieved. Probably then also something has to be added so that you can ask which transport type is used, so that you can do the narrow. Steve, can OCI check this one as author of the tc libs Hi Ivan, Thanks for reporting this issue. The steps for reproducing the problem were very helpful. The implementation of the IIOP Transport Current is only intended to operate under IIOP and will not function when using SSLIOP. It may be possible to extend the Transport Current to work with other transports; if you're interested in this please contact Malcolm Spence at spence_m@ociweb.com. In the meantime, I have committed the following change so that the code gracefully handles this situation: Tue May 20 12:13:16 UTC 2008 Chad Elliott <elliott_c@ociweb.com> * tao/TransportCurrent/IIOP_Current_Impl.cpp: When retrieving the connection handler, check the result of the dynamic_cast and throw a NoContext exception if it is zero. Index: IIOP_Current_Impl.cpp =================================================================== --- IIOP_Current_Impl.cpp (revision 81727) +++ IIOP_Current_Impl.cpp (working copy) @@ -36,7 +36,14 @@ if (ch == 0) throw NoContext (); - return dynamic_cast <TAO_IIOP_Connection_Handler*> (ch); + // Make sure that this connection handler is for IIOP. This + // implementation is not intended to operate under SSLIOP. + TAO_IIOP_Connection_Handler* iiop_ch = + dynamic_cast <TAO_IIOP_Connection_Handler*> (ch); + if (iiop_ch == 0) + throw NoContext (); + + return iiop_ch; #else throw ::CORBA::NO_IMPLEMENT (); #endif Shouldn't we then zap this in the tc_iiop.idl?
/// If this is a "secure" transport, this method will give you
/// the corresponding SSLIOP::Current
readonly attribute ::SSLIOP::Current ssliop_current raises (NoContext);
(In reply to comment #6) > Shouldn't we then zap this in the tc_iiop.idl? > > /// If this is a "secure" transport, this method will give you > /// the corresponding SSLIOP::Current > readonly attribute ::SSLIOP::Current ssliop_current raises (NoContext); I will reopen this Bug and ask Iliyan to take a look. Iliyan, (In reply to comment #7) > (In reply to comment #6) > > Shouldn't we then zap this in the tc_iiop.idl? > > > > /// If this is a "secure" transport, this method will give you > > /// the corresponding SSLIOP::Current > > readonly attribute ::SSLIOP::Current ssliop_current raises (NoContext); > > I will reopen this Bug and ask Iliyan to take a look. Please review this Bug and comment on the intent of the above operation. |
Created attachment 943 [details] Configuration files for server and client. Segmentation fault on Transport::IIOP::Current::remote_host() when using SSLIOP. Same code runs without problem when not using SSLIOP. I've succeeded in reproducing this against ACE_wrappers/TAO/tests/TransportCurrent/IIOP in ACE/TAO version 5.6.3. This is the procedure for reproducing the bug: 1. Download and compile 5.6.3 2. Enter ACE_wrappers/TAO/tests/TransportCurrent/IIOP 3. Copy complete ssl directory from ACE_wrappers/TAO/orbsvcs/tests/Security/BiDirectional to ACE_wrappers/TAO/tests/TransportCurrent/IIOP, or generate certificates by hand 4. Add $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_SSLIOP.la to client_LDADD and server_LDADD in Makefile 5. Create client.conf as in attachment 6. Create server.conf as in attachment 7. Start server with (tcsh): setenv SSL_CERT_FILE ./ssl/ca.pem ./server -ORBsvcconf server.conf 8. Start client with (tcsh): setenv SSL_CERT_FILE ./ssl/ca.pem ./client -ORBsvcconf client.conf At this point client will write some messages and dump core after this one: CRI (31434|3086752656) Test accessing Transport Current from send_request I've made gdb backtrace of this problem, but with against my software, not with TAO test unit. Last 5 (of 37) lines of backtrace are: #0 0x009fc4eb in ACE_SOCK::get_remote_addr (this=0x5c, sa=@0xb7efe130) at /usr/src/debug/ACE_wrappers/ace/OS_NS_sys_socket.inl:223 #1 0x001d4661 in TAO::Transport::IIOP_Current_Impl::remote_host ( this=0x9149180) at TransportCurrent/IIOP_Current_Impl.cpp:103 #2 0x00145e64 in LC::CTRL::Discovery_impl::requestCertification ( this=0x9188bd8, req=0x91f0240 "CONTENT INTENTIONALY REMOVED"...) at discovery.cc:29 #3 0x00133fc3 in POA_LC::CTRL::requestCertification_Discovery::execute ( this=0xb7efe294) at lccontrollerS.cpp:2876 #4 0x00c55e2f in TAO::ServerRequestInterceptor_Adapter_Impl::execute_command ( this=0x915e888, server_request=@0xb7efe924, command=@0xb7efe294) at PI_Server/ServerInterceptorAdapter.cpp:542 #5 0x006de5d7 in TAO::Upcall_Wrapper::upcall (this=0xb7efe2bb, server_request=@0xb7efe924, args=0xb7efe2a4, nargs=2, command=@0xb7efe294, servant_upcall=0xb7efe374, exceptions=0x155b90, nexceptions=3) at PortableServer/Upcall_Wrapper.cpp:106 Hope this is helpfull. Regards, Ivan