Hi, we have a multithreaded application which has been upgraded from the 
earlier solaris version 5.9 to a new set of APIs on Solaris 5.10. 
consequently this application is hanging on this system call, can you please 
suggest why the problem is occuring and what could be a probable resolution.
N.B. the application also makes use of 
WebSphere MQ version 6.0.0.0
Oracle 10.2.0.1.0

Attached to process 6834 with 9 LWPs
t at 1 (l at 1) stopped in __lwp_park at 0xfd3c49a8
0xfd3c49a8: __lwp_park+0x0010:  ta       8
Current function is WrapperLiffeAccessLogon
  100                   ReturnLiffeAPI = 
LiffeAccessLogon(pszTrader,pszPassword,&pcReturn);
dbx: internal warning: set_error_limit called too early
(dbx) where
current thread: t at 1
  [1] __lwp_park(0x0, 0x0, 0x0, 0x0, 0xfc82e000, 0x1), at 0xfd3c49a8
  [2] mutex_lock_queue(0x0, 0xfa350150, 0xfe0f21b8, 0x0, 0x0, 0x1), at 
0xfd3bcde0
  [3] mutex_lock_internal(0xfe0f21b8, 0x0, 0x1, 0x0, 0x10, 0xfd3f3580), at 
0xfd3bd52c
  [4] malloc(0x50, 0xfe364892, 0x118f8, 0xfe26b248, 0xfe0f2000, 0xfd3f3580), at 
0xfe0e071c
  [5] operator new(0x50, 0xfe37da54, 0xfffecf16, 0x13798, 0xfebea780, 0x0), at 
0xfebd7010
  [6] __rwstd::facet_maker<std::ctype<char> >::maker_func(0x0, 0xfe364892, 0x0, 
0x0, 0x0, 0xfd3f3580), at 0xfe26b248
  [7] std::locale::__make_explicit(0xffb8f618, 0xfe37da54, 0xfffecf16, 0x20, 
0xfe26b238, 0x0), at 0xfe30a448
  [8] std::basic_ios<char,std::char_traits<char> >::init(0xffb8f818, 0x0, 0xa, 
0xfe080018, 0xfe37797c, 0xfe37da54), at 0xfe26b138
  [9] std::basic_ios<char,std::char_traits<char> >::basic_ios(0xffb8f818, 
0xfe379bd0, 0x348, 0xfe37797c, 0x10c990, 0x0), at 0xfe26b02c
  [10] 
std::basic_ostringstream<char,std::char_traits<char>,std::allocator<char> 
>::basic_ostringstream(0xffb8f7b8, 0x8, 0xfe37b674, 0xffb8f818, 0xfe37797c, 
0xfe37b680), at 0xfe2c1bfc
  [11] APILiffeApiState::SendSynch(0xfc260224, 0xfa421078, 0x2, 0xffb905f8, 
0x0, 0xffb905f4), at 0xfe5c0204
  [12] APILiffeApiTradingSessionOpen::SendSynch(0xfc260224, 0xfa421078, 0x2, 
0xffb905f8, 0x0, 0xffb905f4), at 0xfe5c0b68
  [13] APILiffeApi::SendSynch(0xfc260210, 0xfa421078, 0x2, 0xffb905f8, 0x0, 
0xffb905f4), at 0xfe5bfa8c
  [14] APICore::LogonReq(0xffb90890, 0xffb90882, 0xffb9085c, 0xffb9360c, 
0x200004, 0xffb91608), at 0xfe5d816c
  [15] LiffeAccessLogon(0xffb90890, 0xffb90882, 0xffb9085c, 0xffb8e11e, 
0xffb8e0ba, 0xff20347d), at 0xfe6055b0
=>[16] WrapperLiffeAccessLogon(XMLbuffer = 0xffbfb85e "<?xml version="1.0" 
encoding="ISO-8859-1" ?>\n<LIFFE>\n<CLASS 
ID="315927"><CBR_LYRIDVRSN>LIFFE01</CBR_LYRIDVRSN><CBR_SEQNO>726385</CBR_SEQNO><LOGIN_ID>I2Q</LOGIN_ID><CBR_MSGTYPE>AccessLogon</CBR_MSGTYPE><API_NAME>LiffeAccessLogon</API_NAME><API_ID>3</API_ID></CLASS>\n\n<CLASS
 
ID="315853"><pszTrader>I2Q</pszTrader><pszPassword>i2qpass</pszPassword></CLASS>\n</LIFFE>",
 LiffeBaseClass_1 = 0xfa491f10, ErrorInfo = 0xfa3f1078, ErrorStruct = 
0xfa411078, NoOfRetries = 0, NackAckType = 0), line 100 in 
"comh_WrapperLiffeAccessLogon.cpp"
  [17] LiffeAPI(LBRObj = CLASS, LoginId = 0x32214 "I2Q", ScenarioId = 0x3d2ec 
"LIFFE_DEFAULTSEND_MULTDB_I2Q_P", fileExtension = 0xffbfc8fe "xml", XMLbuffer = 
0xffbfb85e "<?xml version="1.0" encoding="ISO-8859-1" ?>\n<LIFFE>\n<CLASS 
ID="315927"><CBR_LYRIDVRSN>LIFFE01</CBR_LYRIDVRSN><CBR_SEQNO>726385</CBR_SEQNO><LOGIN_ID>I2Q</LOGIN_ID><CBR_MSGTYPE>AccessLogon</CBR_MSGTYPE><API_NAME>LiffeAccessLogon</API_NAME><API_ID>3</API_ID></CLASS>\n\n<CLASS
 
ID="315853"><pszTrader>I2Q</pszTrader><pszPassword>i2qpass</pszPassword></CLASS>\n</LIFFE>",
 PH_GET_DTLS = STRUCT, PH_PUT_DTLS = STRUCT), line 73 in "comh_liffeapi.cpp"
  [18] main(argc = 3, argv = 0xffbfe4dc), line 696 in "qzliffemainprog.cpp"
 
 
This message posted from opensolaris.org

Reply via email to