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 126.96.36.199 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
- 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 +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
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"