Closed Bug 722625 Opened 13 years ago Closed 13 years ago

Startup crash in `anonymous namespace'::TelemetrySessionData::LoadFromDisk @ memcpy | Pickle::ReadUInt32

Categories

(Toolkit :: Telemetry, defect)

Product:
Toolkit
Component:
Telemetry
Version:
12 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 733977

People

(Reporter: scoobidiver, Assigned: froydnj)

References

Details

(Keywords: crash, regression, Whiteboard: startupcrash)

Crash Data

It first appeared in 12.0a1/20120127, only on 64-bit builds. The regression range might be: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=402b394b6623&tochange=c07595bee6cf Signature memcpy | Pickle::ReadUInt32(void**, unsigned int*) More Reports Search UUID 7c0721f9-5aa6-497a-9a70-7c4e52120130 Date Processed 2012-01-30 12:37:21 Uptime 0 Last Crash 22.2 hours before submission Install Age 2.4 days since version was first installed. Install Time 2012-01-28 03:44:08 Product Firefox Version 12.0a1 Build ID 20120127031148 Release Channel nightly OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture amd64 Build Architecture Info family 6 model 42 stepping 7 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x5a72a16c EMCheckCompatibility False Frame Module Signature [Expand] Source 0 msvcr90.dll memcpy 1 xul.dll Pickle::ReadUInt32 ipc/chromium/src/base/pickle.cc:227 2 xul.dll nsTextNode::AddRef content/base/src/nsTextNode.cpp:156 3 xul.dll `anonymous namespace'::TelemetrySessionData::LoadFromDisk toolkit/components/telemetry/Telemetry.cpp:865 4 xul.dll `anonymous namespace'::LoadHistogramEvent::Run toolkit/components/telemetry/Telemetry.cpp:994 5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:657 6 nspr4.dll MD_CURRENT_THREAD nsprpub/pr/src/md/windows/w95thred.c:308 7 xul.dll nsTextNode::AddRef content/base/src/nsTextNode.cpp:156 8 xul.dll NS_ProcessNextEvent_P obj-firefox/xpcom/build/nsThreadUtils.cpp:245 9 xul.dll CrashReporter::AnnotateCrashReport toolkit/crashreporter/nsExceptionHandler.cpp:1257 10 xul.dll nsThread::Shutdown xpcom/threads/nsThread.cpp:499 11 xul.dll mozilla::crashreporter::LSPAnnotationGatherer::Annotate widget/windows/LSPAnnotator.cpp:78 12 xul.dll nsRunnableMethodImpl<void obj-firefox/dist/include/nsThreadUtils.h:345 13 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:657 14 xul.dll CallCreateInstance obj-firefox/xpcom/build/nsComponentManagerUtils.cpp:170 15 xul.dll MessageLoop::DoWork ipc/chromium/src/base/message_loop.cc:412 16 mozglue.dll choose_arena memory/jemalloc/jemalloc.c:2972 17 xul.dll xul.dll@0xd54bf 18 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:110 19 xul.dll xul.dll@0x3a0177 20 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:201 21 nspr4.dll PR_GetThreadPrivate nsprpub/pr/src/threads/prtpd.c:232 22 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:175 23 msvcr90.dll getenv_helper_nolock 24 xul.dll MessageLoop::current ipc/chromium/src/base/message_loop.cc:85 25 xul.dll nsBaseAppShell::Run widget/xpwidgets/nsBaseAppShell.cpp:189 26 xul.dll nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:220 27 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp:3537 28 msvcp90.dll std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Copy 29 ntdll.dll RtlAllocateMemoryBlockLookaside More reports at: https://crash-stats.mozilla.com/report/list?signature=memcpy%20|%20Pickle%3A%3AReadUInt32%28void**%2C%20unsigned%20int*%29
Dupe of bug 722545?
Well, bug 722545 is a fairly benign, debug-only crash. This is a critical, memory corruption, release-version crash. In fact, I'd back out telemetry on disk in Aurora because of this.
Assignee: nobody → nfroyd
(In reply to Justin Lebar [:jlebar] from comment #2) > In fact, I'd back out telemetry on disk in Aurora because of this. There are no 64-bit Aurora builds.
This is sort of weird. I don't see how any of the arguments to memcpy could be bogus at that point. I'm no expert at reading crash logs. Are there register and/or stack dumps available? Or is the address of the faulting memory location available? And do we have binaries of nightlies stored so we can correlate between the crash dumps and the actual binaries?
> There are no 64-bit Aurora builds. Do you know this can't happen on 64-bit Mac or Linux? Or even on any 32-bit platform? When this happens, the user will be unable to start up Firefox without first deleting their saved histogram data.
This is 64-bit Windows only, and we're waiting on more data to come in from bug 707320 being landed for real.
The latest crash occurs in 13.0a1/20120202.
That's old data from the last time bug 707320 landed. I want to see if anything is different this time. (Given that this is Win64-only, I'm not so sure it should be "critical".)
(In reply to Nathan Froyd (:froydnj) from comment #8) > (Given that this is Win64-only, I'm not so sure it should be "critical".) Stability issues in a program used by 80,000 ADU (32-bit&64-bit builds) are critical.
Only seeing older buildids on this one; seems safe to say it's a dup of 733977.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.