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
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.)
> 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
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.
sounds like a good bug to file.
Crash Signature: [@ nsRefPtr<XPCWrappedNative>::~nsRefPtr<XPCWrappedNative>() | CrashReporter::GetOrInit ]
You need to log in before you can comment on or make changes to this bug.