Closed Bug 606489 Opened 14 years ago Closed 2 years ago

Startup crash in WriteVersion

Categories

(Toolkit :: Startup and Profile System, defect)

Product:
Toolkit
Component:
Startup and Profile System
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: scoobidiver, Unassigned)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [startupcrash][gs])

Crash Data

This is a residual crash signature that exists in 3.6 and trunk builds. All crashes happen at startup. It is #178 top crasher in 3.6.11 for the last 2 weeks. Signature WriteVersion UUID cf7867f6-8f9b-4400-97f0-41f7d2101022 Time 2010-10-22 07:14:26.323994 Uptime 9 Last Crash 75 seconds before submission Install Age 90 seconds since version was first installed. Product Firefox Version 3.6.11 Build ID 20101012113537 Branch 1.9.2 OS Windows NT OS Version 5.1.2600 Service Pack 2 CPU x86 CPU Info GenuineIntel family 6 model 22 stepping 1 Crash Reason EXCEPTION_ACCESS_VIOLATION_WRITE Crash Address 0x1096f9c4 Frame Module Signature [Expand] Source 0 @0xea4f3f5 1 @0xea47e7c 2 xul.dll WriteVersion toolkit/xre/nsAppRunner.cpp:2340 3 xul.dll RemoveComponentRegistries toolkit/xre/nsAppRunner.cpp:2405 More reports at: http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=4&range_unit=days&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=WriteVersion
It is #2 top crasher in 4.0b8pre/20101022 build.
Version: 1.9.2 Branch → Trunk
As bug 602808 that has a signature close to this one, can this bug is a dupe of bug 599603 ?
Depends on: 599603
It is #31 top crasher in 4.0b8pre for the last week.
blocking2.0: --- → ?
blocking2.0: ? → beta8+
An interesting comment from the 3.6.x crash data is that the person crashed after installing the vshare plugin - http://cdn.toolbarhome.com/partners/vshareus/download/vshare-plugin.exe is one place I found it. Will take a look at some more of the crash comments on 3.6.x.
We seem to be missing symbols for NSPR here? Either way I can't see how we could be crashing here.
Component: XULRunner → Startup and Profile System
QA Contact: xulrunner → startup
Summary: crash at startup [@ WriteVersion ] → crash at startup [@ WriteVersion ][@ arena_dalloc_small | nsCOMPtr_base::~nsCOMPtr_base() | XRE_main ][@ arena_dalloc_small | nsRefPtr<nsIDOMEventListener>::~nsRefPtr<nsIDOMEventListener>() | XRE_main ][@ nsCOMPtr_base::~nsCOMPtr_base() | WriteVersion ]
when comparing rank of 3.6.11 and the just released 3.6.12 this has taken a big jump in 3.6.12 http://people.mozilla.com/~chofmann/crash-stats/20101028/compare-rank-3612-3611.txt list-3.6.12 . list-3.6.11 . . Signatures 5 114 WriteVersion
(In reply to comment #7) > We seem to be missing symbols for NSPR here? Either way I can't see how we > could be crashing here. We're not missing symbols for NSPR, we're apparently missing the NSPR module in that stack trace. If you look at the modules tab, the NSPR module is there (and if you look at the raw dump you can see its base address), but those top two frames are out in the middle of nowhere. It's possible something got horribly confused. Loading a different NSPR in process and then unloading it? I don't know.
Seems to me like this is probably a candidate to move to beta9 since there isn't a lot of activity on it and there are a number of other topcrashes that have pushed it down in the list. It's still there though so it's shouldn't disappear entirely. I think we should triage to the next release.
Bumping to beta9. Just want a quick turnaround on 8.
blocking2.0: beta8+ → beta9+
Without a regression range, or STR, or any idea of what could be causing this, I'm not sure how we can block on it. If we believe that this is a big stability issue, let's assign some resources to investigate and then renominate for blocking once we have that information.
blocking2.0: beta9+ → -
The WriteVersion signature has risen up to #123 with 38 crashes per million ADU on 4.0* - but https://crash-stats.mozilla.com/report/list?signature=WriteVersion says it happens on all kinds of versions. Looks like a lot of those people are on XP but there are other Windows versions around as well, and MSCTF.dll is present in a lot of reports, which seems to come from some Microsoft Text Framework. The stacks still look very much like the one in comment #0 and it seems to be very early in startup as all reports I'm seeing in the list are within 5 seconds of launch, most even at 0 or 1.
[comment 14 prematurely committed] @ WriteVersion is a topcrash for thunderbird 3.1.10 and has a reporter at http://getsatisfaction.com/mozilla_messaging/topics/thunderbird_crash_at_morning#reply_5735480 bp-df0acdcf-20ae-490a-b374-819922110606 is an example for TB5.0 However, a spot check of TB crashes doesn't show any with RemoveComponentRegistries that appear in the FF stack. There is also a lone TB Mac crash bp-28d3b31d-352d-409f-ae79-32a0d2110511 nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) | WriteVersion
Whiteboard: [tbird topcrash → [tbird topcrash?]
Crash Signature: [@ WriteVersion ] [@ arena_dalloc_small | nsCOMPtr_base::~nsCOMPtr_base() | XRE_main ] [@ arena_dalloc_small | nsRefPtr<nsIDOMEventListener>::~nsRefPtr<nsIDOMEventListener>() | XRE_main ] [@ nsCOMPtr_base::~nsCOMPtr_base() | WriteVersion ]
firefox 5 crashes are WriteVersion. But last crash for nsCOMPtr_base::~nsCOMPtr_base() | WriteVersion is almost 2 months ago, firefox 4 bp-b1286eba-ffd7-4432-ba14-a60a02110616. (thunderbird has none) WriteVersion has thunderbird 5 crashes, eg bp-b228e6ef-5c77-4959-9cb3-5e4fa2110725
Crash Signature: [@ WriteVersion ] [@ arena_dalloc_small | nsCOMPtr_base::~nsCOMPtr_base() | XRE_main ] [@ arena_dalloc_small | nsRefPtr<nsIDOMEventListener>::~nsRefPtr<nsIDOMEventListener>() | XRE_main ] [@ nsCOMPtr_base::~nsCOMPtr_base() | WriteVersion ] → [@ WriteVersion ] [@ arena_dalloc_small | nsCOMPtr_base::~nsCOMPtr_base() | XRE_main ] [@ arena_dalloc_small | nsRefPtr<nsIDOMEventListener>::~nsRefPtr<nsIDOMEventListener>() | XRE_main ] [@ nsCOMPtr_base::~nsCOMPtr_base() | WriteVersion ]
Whiteboard: [tbird topcrash?] → [tbird topcrash?][gs]
Summary: crash at startup [@ WriteVersion ][@ arena_dalloc_small | nsCOMPtr_base::~nsCOMPtr_base() | XRE_main ][@ arena_dalloc_small | nsRefPtr<nsIDOMEventListener>::~nsRefPtr<nsIDOMEventListener>() | XRE_main ][@ nsCOMPtr_base::~nsCOMPtr_base() | WriteVersion ] → Startup crash in WriteVersion
firefox v14 bp-c5a4f181-c2ae-4cc7-b6db-bbca22120407 but almost non-existent in thunderbird afaict
Whiteboard: [tbird topcrash?][gs] → [gs]
Whiteboard: [gs] → [startupcrash][gs]
Crash Signature: [@ WriteVersion ] [@ arena_dalloc_small | nsCOMPtr_base::~nsCOMPtr_base() | XRE_main ] [@ arena_dalloc_small | nsRefPtr<nsIDOMEventListener>::~nsRefPtr<nsIDOMEventListener>() | XRE_main ] [@ nsCOMPtr_base::~nsCOMPtr_base() | WriteVersion ] → [@ WriteVersion ] [@ arena_dalloc_small | nsCOMPtr_base::~nsCOMPtr_base() | XRE_main ] [@ arena_dalloc_small | nsRefPtr<nsIDOMEventListener>::~nsRefPtr<nsIDOMEventListener>() | XRE_main ] [@ nsCOMPtr_base::~nsCOMPtr_base() | WriteVersion ] [@ arena_da…
Severity: critical → S2

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: S2 → S3

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.