Closed Bug 722625 Opened 12 years ago Closed 12 years ago

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

Categories

(Toolkit :: Telemetry, defect)

12 Branch
x86_64
Windows 7
defect
Not set
critical

Tracking

()

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: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.