start-up crash under Windows XP [@ nsRefPtr<XPCWrappedNative>::~nsRefPtr<XPCWrappedNative>() | CrashReporter::GetOrInit ]

VERIFIED DUPLICATE of bug 597262

Status

()

--
critical
VERIFIED DUPLICATE of bug 597262
8 years ago
8 years ago

People

(Reporter: scoobidiver, Unassigned)

Tracking

({crash, regression})

Trunk
x86
Windows XP
crash, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

8 years ago
This is a new crash signature in trunk build.
It is #37 top crasher in b7pre/20100928 build.

One Russian comment says : "I have tried reinstalling, tried to clean the registry - nothing works. All the time jumps "Mozilla Crash reporter". I do not know what to do. "

Signature	nsRefPtr<XPCWrappedNative>::~nsRefPtr<XPCWrappedNative>() | CrashReporter::GetOrInit
UUID	5c569299-5204-40f2-a922-be3152100928
Time 	2010-09-28 23:34:32.316281
Uptime	1
Install Age	1 seconds since version was first installed.
Product	Firefox
Version	4.0b7pre
Build ID	20100928041914
Branch	2.0
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	AuthenticAMD family 15 model 44 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x8
Processor Notes 	WARNING: Json file missing Add-ons

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsRefPtr<XPCWrappedNative>::~nsRefPtr<XPCWrappedNative> 	obj-firefox/dist/include/nsAutoPtr.h:969
1 	xul.dll 	CrashReporter::GetOrInit 	toolkit/crashreporter/nsExceptionHandler.cpp:714
2 	xul.dll 	CrashReporter::SetupExtraData 	toolkit/crashreporter/nsExceptionHandler.cpp:783
3 	xul.dll 	nsXREDirProvider::GetUserAppDataDirectory 	toolkit/xre/nsXREDirProvider.h:81
4 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:2966
5 	kernel32.dll 	CloseHandle 	
6 	mozcrt19.dll 	arena_dalloc 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4284
7 	mozcrt19.dll 	__dllonexit 	obj-firefox/memory/jemalloc/crtsrc/onexit.c:276
8 	mozcrt19.dll 	_fclose_nolock 	obj-firefox/memory/jemalloc/crtsrc/fclose.c:108
9 	mozcrt19.dll 	_fclose_nolock 	obj-firefox/memory/jemalloc/crtsrc/fclose.c:127

More reports at :
http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsRefPtr%3CXPCWrappedNative%3E%3A%3A~nsRefPtr%3CXPCWrappedNative%3E%28%29%20|%20CrashReporter%3A%3AGetOrInit
(Reporter)

Updated

8 years ago
Component: General → Breakpad Integration
Product: Core → Toolkit
QA Contact: general → breakpad.integration
Probably a dupe of bug 597262, the stacks look incredibly similar. The frame at the top is kind of goofily-named in both, but I think that's mostly due to COMDAT folding by the linker. (nsCOMPtr and nsRefPtr are pretty similar, it wouldn't surprise me to find that some of their methods had been folded together.)
(Reporter)

Comment 2

8 years ago
> Probably a dupe of bug 597262
Except that bug 597262 is for 3.6 and trunk builds.
This bug is only for trunk builds. The crashes are discontinuous according to the builds and the first appearance is older than 4 weeks, so the regression range can not be determined.
Yes, I think it's the same exact crash, just showing up under a slightly different signature (nsRefPtr vs. nsCOMPtr), which is why it is graphing differently on crash-stats.
I'm duping this. I know it's confusing, but I'm 99.9% certain it's the same crash.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 597262

Comment 5

8 years ago
fwiw, i've seen msvc do that folding, it really is smart enough to do it and generally does it.
Status: RESOLVED → VERIFIED
Would be nice if it either a) consistently chose the same name for the folded COMDATs or b) provided a way to distinguish them from the debug symbols. It might be worthwhile taking a look at one of our nightly builds and trying to figure out just how many things get folded together, and having either our buildsymbols process or Socorro do cleanup on those signatures.

Comment 7

8 years ago
sounds like a good bug to file.
(Assignee)

Updated

8 years ago
Crash Signature: [@ nsRefPtr<XPCWrappedNative>::~nsRefPtr<XPCWrappedNative>() | CrashReporter::GetOrInit ]
You need to log in before you can comment on or make changes to this bug.