556.00 KB, application/octet-stream
Created attachment 701556 [details] trace back, containing main thread traceback and mutex-holding thread traceback User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130112 Firefox/21.0 Build ID: 20130112030947 Steps to reproduce: 1 came to some site which using HTTPS protocol 2 browse several pages ( more or less) using windows 7 sp1. Firefox nightly build 20130112030947 about:supports : http://pastebin.com/xGGZYyGr Actual results: Firefox stop response, Debugger shows the main thread stops in nssTrustDomain_RemoveTokenCertsFromCache, which calls function PR_Lock / PZ_LOCK(tdcache.c:441). [See 1_mainThread.png for the traceback] debugger shows the mutex is hold by another thread, when checking holding thread, it shows that thread stops in md_UnlockAndPostNotifies, running LeaveCriticalSection(w95cv.c:137) and seems stops in it. when this happens, md_UnlockAndPostNotifies parameter "lock" seems always be 0, however, it isn't naturally be 0, for a break point break on condition lock==NULL will never be stopped . [see 2_holdMutexThread.png for the traceback] Expected results: never be happen.
Dear Developer: With several day’s test, I found that seems this problem isn’t caused by Firefox itself. But Caused by a plugin which used by CCB - That means China Construction Bank – for Secure (so called) payment. I uninstalled it three days ago, and seems such problem has been totally resolved now. For Chinese user’s reference. Such plugins is called “个人客户E路护航网银安全组件” , when installed that, it will setup several plugins into Firefox, and I am not sure which causes such a problem. And, I’m not sure where to report such a bug. So I guess this situation will lasts for some time. Hope it’s helpful. Linzhe Li
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.