Last Comment Bug 645714 - Crash in mozilla::TimeStamp::Now @ PR_Lock
: Crash in mozilla::TimeStamp::Now @ PR_Lock
Status: RESOLVED FIXED
[mobile-crash], str-wanted
: crash
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: ARM Android
: -- critical (vote)
: mozilla13
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 716345
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-28 09:15 PDT by Scoobidiver (away)
Modified: 2012-05-31 02:20 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
affected


Attachments

Description Scoobidiver (away) 2011-03-28 09:15:56 PDT
It is #21 top crasher in 4.0.

There are two kinds of stack traces:
Frame 	Module 	Signature [Expand] 	Source
0 	libnspr4.so 	PR_Lock 	nsprpub/pr/src/pthreads/ptsynch.c:216
1 	libxul.so 	mozilla::TimeStamp::Now 	xpcom/ds/TimeStamp.cpp:115
2 	libxul.so 	TimerThread::Run 	nsTArray.h:139
3 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
4 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:250
5 	libxul.so 	nsThread::ThreadFunc 	xpcom/threads/nsThread.h:85
6 	libnspr4.so 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c:190
7 	libc.so 	libc.so@0xfd97 	
8 	libc.so 	libc.so@0xf863 	

Frame 	Module 	Signature [Expand] 	Source
0 	libnspr4.so 	PR_Lock 	nsprpub/pr/src/pthreads/ptsynch.c:216
1 	libxul.so 	mozilla::TimeStamp::Now 	xpcom/ds/TimeStamp.cpp:115
2 	libxul.so 	nsTimerImpl::SetDelayInternal 	TimeStamp.h:195
3 	libxul.so 	nsTimerImpl::InitCommon 	xpcom/threads/nsTimerImpl.cpp:231
4 	libxul.so 	nsTimerImpl::InitWithFuncCallback 	xpcom/threads/nsTimerImpl.cpp:247
5 	libxul.so 	mozilla::scache::StartupCache::ResetStartupWriteTimer 	startupcache/StartupCache.cpp:468
6 	libxul.so 	mozilla::scache::StartupCache::PutBuffer 	startupcache/StartupCache.cpp:287
7 	libxul.so 	mozJSComponentLoader::WriteScript 	js/src/xpconnect/loader/mozJSComponentLoader.cpp:940
8 	libxul.so 	mozJSComponentLoader::GlobalForLocation 	js/src/xpconnect/loader/mozJSComponentLoader.cpp:1228
9 	libxul.so 	mozJSComponentLoader::LoadModuleImpl 	js/src/xpconnect/loader/mozJSComponentLoader.cpp:697
10 	libxul.so 	mozJSComponentLoader::LoadModuleFromJAR 	js/src/xpconnect/loader/mozJSComponentLoader.cpp:661
11 	libxul.so 	nsComponentManagerImpl::KnownModule::Load 	xpcom/components/nsComponentManager.cpp:962
12 	libxul.so 	nsFactoryEntry::GetFactory 	xpcom/components/nsComponentManager.cpp:1948
13 	libxul.so 	nsComponentManagerImpl::CreateInstanceByContractID 	xpcom/components/nsComponentManager.cpp:1323
14 	libxul.so 	nsComponentManagerImpl::GetServiceByContractID 	xpcom/components/nsComponentManager.cpp:1676
15 	libxul.so 	CallGetService 	nsComponentManagerUtils.cpp:95
16 	libxul.so 	nsGetServiceByContractID::operator 	nsComponentManagerUtils.cpp:279 
...

More reports at:
https://crash-stats.mozilla.com/report/list?product=Fennec&range_value=4&range_unit=weeks&signature=PR_Lock
Comment 1 Naoki Hirata :nhirata (please use needinfo instead of cc) 2011-09-20 11:28:33 PDT
On various devices, most current crash report comes from Droid Bionic:
https://crash-stats.mozilla.com/report/index/ad8115b5-d218-4a9a-9ef2-243892110913
Comment 3 Naoki Hirata :nhirata (please use needinfo instead of cc) 2011-11-06 17:52:49 PST
Also occurs in native fennec: 
https://crash-stats.mozilla.com/report/index/6fab3249-781e-4137-968a-d13eb2111105
Comment 4 Naoki Hirata :nhirata (please use needinfo instead of cc) 2011-11-21 14:17:30 PST
Marking as P3 : bug has existed in XUL, firefox, need str
Comment 6 Scoobidiver (away) 2012-01-26 11:22:54 PST
Stacks are more various than the two ones in comment 0.
The fix of bug 716345 would help to divide it in several sub-bugs.
Comment 8 Naoki Hirata :nhirata (please use needinfo instead of cc) 2012-02-28 16:09:58 PST
Happens in both XUL/Native

https://crash-stats.mozilla.com/report/list?product=Fennec&product=FennecAndroid&query_search=signature&query_type=contains&query=PR_Lock&reason_type=contains&date=02%2F29%2F2012%2000%3A05%3A58&range_value=30&range_unit=days&hang_type=any&process_type=any&do_query=1&admin=1&signature=PR_Lock

Haven't seen it for 13?  Not sure if the changes due to timestamp to uptime made a difference?
Comment 9 Jeff Muizelaar [:jrmuizel] 2012-05-30 21:55:15 PDT
We no longer use the NSPR TimeStamp implementation so this should be fixed.

Note You need to log in before you can comment on or make changes to this bug.