Crash in mozilla::TimeStampValue::operator-
Categories
(Core :: General, defect, P3)
Tracking
()
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...
Comment 1•8 years ago
|
||
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
Comment 2•7 years ago
|
||
Too late for firefox 52, mass-wontfix.
Comment 3•6 years ago
|
||
Many of the crashes have dom::indexedDB on the stack, e.g.: bp-fb1c0d07-ea54-41bd-a335-574e00180530 Maybe some thread issue?
Updated•6 years ago
|
Comment 4•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 5•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 6•3 years ago
|
||
¡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
Comment 7•3 years ago
|
||
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.
Updated•2 years ago
|
Description
•