606489 - Startup crash in WriteVersion

Status: RESOLVED WORKSFORME

(Toolkit :: Startup and Profile System, defect)

Description

[Scoobidiver (away)]

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

Comment 1

[Scoobidiver (away)]

It is #2 top crasher in 4.0b8pre/20101022 build.

Comment 2

[Scoobidiver (away)]

As bug 602808 that has a signature close to this one, can this bug is a dupe of bug 599603 ?

Comment 4

[Scoobidiver (away)]

It is #31 top crasher in 4.0b8pre for the last week.

Comment 6

[Marcia Knous [:marcia]]

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.

Comment 7

[Dave Townsend [:mossop]]

We seem to be missing symbols for NSPR here? Either way I can't see how we could be crashing here.

Comment 8

[chris hofmann]

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

Comment 9

[(not currently active) Ted Mielczarek]

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

Comment 10

[Sheila Mooney]

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.

Comment 11

[Damon Sicore (:damons)]

Bumping to beta9.  Just want a quick turnaround on 8.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 13

[Robert Kaiser]

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

[Wayne Mery (:wsmwk)]

https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2011-06-06%2003%3A00%3A00&signature=WriteVersion&version=Thunderbird%3A3.1.10

Comment 15

[Wayne Mery (:wsmwk)]

[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

Comment 16

[Wayne Mery (:wsmwk)]

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

Comment 17

[Wayne Mery (:wsmwk)]

firefox v14 bp-c5a4f181-c2ae-4cc7-b6db-bbca22120407

but almost non-existent in thunderbird afaict

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.