Closed Bug 1306867 Opened 8 years ago Closed 4 years ago

Crash in mozilla::TimeStampValue::operator-

Categories

(Core :: General, defect, P3)

49 Branch
All
Windows
defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox49 --- wontfix
firefox-esr45 --- wontfix
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- wontfix
firefox90 --- wontfix
firefox91 --- wontfix
firefox92 --- wontfix

People

(Reporter: philipp, Unassigned)

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-41928f31-eba5-4177-bc48-f27852161001.
=============================================================
Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	mozglue.dll 	mozilla::TimeStampValue::operator-(mozilla::TimeStampValue const&) 	mozglue/misc/TimeStamp_windows.cpp:392
1 	xul.dll 	TimerThread::AddTimerInternal(nsTimerImpl*) 	xpcom/threads/TimerThread.cpp:659
2 	xul.dll 	TimerThread::AddTimer(nsTimerImpl*) 	xpcom/threads/TimerThread.cpp:585
3 	xul.dll 	nsTimerImpl::InitCommon(unsigned int, unsigned int) 	xpcom/threads/nsTimerImpl.cpp:267
4 	xul.dll 	nsTimerImpl::InitWithFuncCallbackCommon(void (*)(nsITimer*, void*), void*, unsigned int, unsigned int, mozilla::Variant<int const, char const*, void (*)(nsITimer*, void*, char*, unsigned int)>) 	xpcom/threads/nsTimerImpl.cpp:287
5 	xul.dll 	nsTimerImpl::InitWithNameableFuncCallback(void (*)(nsITimer*, void*), void*, unsigned int, unsigned int, void (*)(nsITimer*, void*, char*, unsigned int)) 	xpcom/threads/nsTimerImpl.cpp:319
6 	xul.dll 	nsTimeout::InitTimer(unsigned int) 	dom/base/nsGlobalWindow.cpp:553
7 	xul.dll 	nsGlobalWindow::RescheduleTimeout(nsTimeout*, mozilla::TimeStamp const&, bool) 	dom/base/nsGlobalWindow.cpp:12391
8 		@0xcf48 	
9 	xul.dll 	nsGlobalWindow::RunTimeout(nsTimeout*) 	dom/base/nsGlobalWindow.cpp:12556
10 	xul.dll 	nsGlobalWindow::TimerCallback(nsITimer*, void*) 	dom/base/nsGlobalWindow.cpp:12785
11 	kernel32.dll 	GetCurrentThreadId 	
12 	xul.dll 	nsTimerEvent::Run() 	xpcom/threads/TimerThread.cpp:286
13 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1067
14 	xul.dll 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:100
15 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:228
16 	xul.dll 	NS_DispatchToCurrentThread(nsIRunnable*) 	xpcom/glue/nsThreadUtils.cpp:173

this is a low level crash (0.05% on beta currently) on windows systems that has been around for a while...
Crash volume for signature 'mozilla::TimeStampValue::operator-':
 - nightly (version 52): 3 crashes from 2016-09-19.
 - aurora  (version 51): 1 crash from 2016-09-19.
 - beta    (version 50): 69 crashes from 2016-09-20.
 - release (version 49): 185 crashes from 2016-09-05.
 - esr     (version 45): 19 crashes from 2016-06-01.

Crash volume on the last weeks (Week N is from 10-03 to 10-09):
            W. N-1  W. N-2
 - nightly       2       1
 - aurora        1       0
 - beta         60       9
 - release     141      44
 - esr           0       0

Affected platform: Windows

Crash rank on the last 7 days:
           Browser   Content     Plugin
 - nightly #464
 - aurora  #1650
 - beta    #275      #533
 - release #410      #424
 - esr
Too late for firefox 52, mass-wontfix.
Many of the crashes have dom::indexedDB on the stack, e.g.:
bp-fb1c0d07-ea54-41bd-a335-574e00180530
Maybe some thread issue?
Component: General → DOM: IndexedDB
Priority: -- → P3

Gabriele, we might want a prefix for this crash? I See nothing related to IndexedDB in any of the traces I clicked on, and different origins, too.

Flags: needinfo?(gsvelto)
Component: Storage: IndexedDB → General

Looking at the different crashes I'd close this as INVALID at this point: the stacks are all different as well as the crash addresses. This seems like random crashes coming from machines with faulty memory rather than a valid issue. What reinforces this idea is that I could even find a crash from a machine with ECC memory:

https://crash-stats.mozilla.org/report/index/b4d0f069-8763-4103-bb68-ed32c0191224

The crash reason is EXCEPTION_IN_PAGE_ERROR_READ / STATUS_CRC_ERROR which means that an uncorrectable memory error was detected and the process was killed because of that.

Flags: needinfo?(gsvelto)
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID

¡Hola Gabriele!

Hope these lines find you well.

Reviewing about:crashes on this Nightly I found
https://crash-stats.mozilla.org/report/index/c285fae4-9d44-49e5-8283-3ce0d0210624
which per
https://crash-stats.mozilla.org/signature/?product=Firefox&signature=mozilla%3A%3ATimeStampValue%3A%3Aoperator-

I'm 98% certain that at least in the case of my crash report memory corruption is unlikely, this is a new laptop and I've recently ran the memory diagnostics on it and no memory errors were found.

Should this be a separate bug or is this one still the one that's relevant?

FWIW I've updated the flags per the links above.

¡Gracias!
Alex

Flags: needinfo?(gsvelto)

I've looked at the crashes under that signature and the stacks are all different, so different that they look random. Given the low volume and the fact that the first function on the stack is very common it's possible that they're being caused by a different bug which sometimes manifests itself under this signature. Unless the crash repeated itself for you with the same signature and stack I don't think there's anything actionable under that signature.

Flags: needinfo?(gsvelto)
You need to log in before you can comment on or make changes to this bug.