Hi Nishant, My comments in-line below...
Nishant Arora wrote: > > Hi Max / Frank the details are as below, > > > http://www.opensolaris.org/jive/thread.jspa?threadID=59721&tstart=0 > > 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, why > could the application be hanging because of ?? What is the "new set of APIs on Solaris 5.10"? > > N.B. the application also makes use of > WebSphere MQ version 6.0.2.3 > Oracle 10.2.0.1.0 > > Attached to process 6834 with 9 LWPs > [EMAIL PROTECTED] ([EMAIL PROTECTED]) 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: [EMAIL PROTECTED] > [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 What are the other threads doing in the application (i.e., get stack trace of all threads via pstack)? One of them is holding the lock that thread id 1 is hanging on. You can use mdb to find which thread holds the lock, but it is probably easier to do with dbx. However, I don't know how to do this with dbx... max _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
