RP/TUX 9.1 - CORBA server crashes with create_active_object_reference and USER_AUTH (Doc ID 777982.1)

Last updated on NOVEMBER 04, 2016

Applies to:

Oracle Tuxedo / Tuxedo / 9.1
Information in this document applies to any platform


Customer has a CORBA client/server application. An application process, named DSSserver, terminates at start-up. The
DSServer's Server::initialize() is allocating a C++ object and calling TP::create_active_object_reference() with that
allocated pointer. This DSServer uses LDAP client, but not Oracle or DB2 client.

Here is the Stack Trace:
t@1 (l@1) program terminated by signal SEGV (no mapping at the fault address) 
0xfdccc7e4: CallAuthorizeAuditOper+0x0624: ld [%o0 + 92], %l5 
Current function is Server::initialize 
410 s_v_fact_ref = 
(dbx) where 
current thread: t@1 
[1] TGIOPProtocol::CallAuthorizeAuditOper(0x72fb8, 0xc3b10, 0xc4348, 0x2, 0xffbfc7a8, 0x84380), at 0xfdccc7e4 
[2] InProcReqSender::Reply(0x3e3b0, 0x72fb8, 0xffbfc7a8, 0xc4348, 0xc3b10, 0xfdcee498), at 0xfed0179c 
[3] ObjectAdapterImpl::ProcessRequestServerRequest(0xffbfc7a8, 0xc3b10, 0x1000000, 0xa9860, 0x1, 0xfebcd90c), at
[4] ObjectAdapterImpl::ProcessRequests(0xa9860, 0x1, 0x1, 0xffbfc7a8, 0x18400, 0xa9870), at 0xfebcba60 
[5] InProcReqSender::Send(0xffbfc7a8, 0xffbfc44c, 0xffbfc454, 0x0, 0xc3238, 0xffbfc460), at 0xfed00da4 
[6] GIOPProtocolTower::Invoke(0xfee05084, 0xc3238, 0xffbfc7a8, 0xffbfc4c4, 0xfedf7c44, 0xc3238), at 0xfecf7ed0 
[7] RequestImpl::InvokeRequest(0xc3238, 0x0, 0xffbfc7a8, 0xab2f0, 0x0, 0xfeceac48), at 0xfece5a80 
[8] RequestImpl::invoke(0xc3238, 0xfee03fb0, 0x113b28, 0x15cd7c, 0xfedf7c44, 0x3b3f0), at 0xfece41c4 
[9] ObjectStateManager::activateObjectReference(0x800, 0xcd5c8, 0xa78, 0xff394bc4, 0xfee03fb0, 0x0), at 0xfee89760 
[10] TP::create_active_object_reference(0xcd5c8, 0x294fd, 0xc28b0, 0x800, 0xffbfcb10, 0x399d8), at 0xfeea77a8 
[11] Server::initialize(this = 0x5edf0, argc = 3, argv = 0xc1760), line 410 in "DSServer.cpp" 
[12] OrbMain::startup(0x773f0, 0x3b090, 0xffbfef7c, 0xfeed4224, 0xfeed0f80, 0x68bd0), at 0xfee8d650 
[13] server_init(0x11, 0xffbfef7c, 0x800, 0x42100, 0x399d8, 0xfeed0f80), at 0xfee8eeb8 
[14] tpsvrinit(0x11, 0xffbfef7c, 0xffbfe964, 0x14f24, 0xfe9fad64, 0x399c0), at 0x24ab4 
[15] _tmmain(0x11, 0xffbfef7c, 0x0, 0x5fc88, 0x2, 0xfea5da84), at 0xfe965f30 
[16] _tmstartserver(0x11, 0xffbfef7c, 0x3a4d8, 0x5fc88, 0x0, 0xfea5da84), at 0xfe952d34 
[17] main(0x11, 0xffbfef7c, 0xffbfefc4, 0x3a400, 0xfddb69c0, 0x5edf0), at 0x18364 

Interesting facts about this issue:
1. This problem only happens with create_active_object_reference(). If they change it to create_object_reference(),
the problem disappears.
2. This problem also happens only when security is set to USER_AUTH. If set the security to NONE, problem disappears
(server doesn't crash).
3. The problem also disappears when Request Level Interceptor (RLI) is not registered. 

Customer wants to use create_active_object_reference() with SECURITY set to USER_AUTH and with RLI registered. In
which case, the DSSserver is failing.

Solaris 9.0
Tuxedo 9.1 
32 Bit


Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms