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

Status: VERIFIED DUPLICATE of bug 597262

(Toolkit :: Crash Reporting, defect)

Description

[Scoobidiver (away)]

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

Comment 1

[(not currently active) Ted Mielczarek]

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.)

Comment 2

[Scoobidiver (away)]

> 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.

Comment 3

[(not currently active) Ted Mielczarek]

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.

Comment 4

[(not currently active) Ted Mielczarek]

I'm duping this. I know it's confusing, but I'm 99.9% certain it's the same crash.

Comment 5

[timeless]

fwiw, i've seen msvc do that folding, it really is smart enough to do it and generally does it.

Comment 6

[(not currently active) Ted Mielczarek]

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

[timeless]

sounds like a good bug to file.