Siebel Administration > Siebel crash with multiple tabs - how to analyze and fix this
Siebel Crash while using multiple tabs - Multiple tabs in Internet Explorer was introduced and is not supported in Siebel. While using this in 8.1.x, what happens is that the Siebel object manager crashes, logging out all connected users and generating core dumps in *NIX environments plus all other files that a crash generates. Users can use multiple tabs in Internet Explorer but may use Siebel only in one tab.
Oracle has proposed a fix in version 8.1.1.7 fix pack Until then the official solution is to install the quickfix QF03BN.
This is what Oracle says
The fix should address the scenario where a user uses multiple tabs, they experience an incorrect display and his session will be in an invalid state. At this point a crash will not occur and when the attempt to navigate to the invalid view they will get the error dialog stating that the view "xxxxx" (the in-existing one) does not exist. Their session will still be in a state where they won't be able to use it and will have to disconnect from the session. The browser will have to be closed (using the X button on IE) and new session in a new browser opened but the OM will not crash and so all the users connected to the same OM process will not be impacted as they are currently.
Symptoms of multiple tab crash in Solaris
1) Call stack size for multi tab crash is 2939 bytes
2) - CALL STACK file content will be - sscaswbc +0xe90fb = CSSSWEHtmlHIContentHandler::CS_ShowProcessCommandError() +0x25b sscaswbc +0xd5434 = CSSSWEContentHandler::ShowProcessCommandError() +0x1b4 sscaswbc +0xa81de = CSSSWECmdProcessor::ProcessCommand() +0xa0e sscaswbc +0xa8442 = CSSSWECmdProcessor::ProcessCommand() +0xc2 sscaswbc +0x1d1422 = CSSServiceSWEIface::Request() +0x2e2 sscaswbc +0x1d2c5e = CSSServiceSWEIface::DoInvokeMethod() +0x8fe sscfom +0x188da = CSSService::InvokeMethod() +0x1ba sstcsiom +0x6d6a = CSSSIOMSession::ModInvokeSrvcMethod() +0x10a sstcsiom +0x7534 = CSSSIOMSession::RPCMiscModel() +0x434
sstcsiom +0xe769 = CSSSIOMSession::HandleRPC() +0x369 sssasos +0x65e6 = CompCleanup() +0x3bb6 sssasos +0x5a95 = CompCleanup() +0x3065 sssasos +0x1a35 = CSSSISObject::operator=() +0x9f5 sssasos +0x2135 = CompHandleMsg() +0x485 siebmtshmw +0x494e siebmtshmw +0x1ffa1 = GetSmiTaskAPI() +0x6d21 siebmtshmw +0x23921 = SmiInProcMsgHandler() +0x2051 siebmtshmw +0x15e65 = SmiBeginTrace() +0x3155 siebmtshmw +0x1741f = GetSmiWorkQObj() +0x148f siebmtshmw +0xc7c7 = SmiCleanupDetTask() +0x3bd7 sslcosd +0x2132 = OSDThreadPrivIsInit() +0x1d2 sslcosd +0x21bc = OSDThreadPrivIsInit() +0x25c MSVCR71 +0x9565 = endthreadex() +0xa0 kernel32 +0x2482f = GetModuleHandleA() +0xdf
3) Additionally from the FDR file produced it can be seen that a GotoView method is called to move the user to a view. The view name is erroneous and appears as the name of the field on the applet appended by "view" Example: Description View
|