499774 - startup crash [@ nsAString_internal::Capacity] interface nsIMsgFolder changed without required uuid bump

Status: RESOLVED FIXED

(MailNews Core :: Filters, defect)

Description

[Wayne Mery (:wsmwk)]

this is new topcrash for 3.0b3pre - at #1 in the last 7 days
99% are within 1-2 second of startup.

first crash is 20090524031837 build, but with <1 crash per day the regression could easily have begun 2-3 days prior.  most recent is 20090621031956 build. none have comments. based on reported OS looks like at least 3 users.

bp-df4a6c78-7b15-4eff-a199-774382090621

0	xpcom_core.dll	nsAString_internal::Capacity	 xpcom/string/src/nsTSubstring.cpp:282
1	xpcom_core.dll	nsAString_internal::MutatePrep	xpcom/string/src/nsTSubstring.cpp:98
2	xpcom_core.dll	nsAString_internal::ReplacePrep	xpcom/string/src/nsTSubstring.cpp:224
3	xpcom_core.dll	nsAString_internal::AssignASCII	xpcom/string/src/nsTSubstring.cpp:378
4	thunderbird.exe	nsMsgIncomingServer::ToString	mailnews/base/util/nsMsgIncomingServer.cpp:670
5	xpcom_core.dll	NS_InvokeByIndex_P	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101
6	xpcom_core.dll	xptiInterfaceInfo::GetMethodInfo	xpcom/reflect/xptinfo/src/xptiprivate.h:706
7	thunderbird.exe	XPCConvert::NativeInterface2JSObject	js/src/xpconnect/src/xpcconvert.cpp:1146

Comment 1

[Mark Banner (:standard8)]

This looks to me like something pretty badly went wrong - we possibly ran out of memory. What it is doing at that point is assigning a literal string to an nsString. So unless there's a core issue somewhere, I'm not sure we can do much about this.

Comment 2

[[e-mail]]

Somebody changed a .idl without revving the IID :-(

The caller is probably not actually trying to call ToString().

Comment 3

[Michiel van Leeuwen (email: mvl+moz@)]

Whoops. I indeed forgot to update the iid. The patch was for bug 464770, btw (push went wrong, and comment got lost)
So this crash is likely caused by an binary extension? If the iid is changed, the extension will break and no longer crash?

Comment 4

[[e-mail]]

(In reply to comment #3)
> So this crash is likely caused by an binary extension? If the iid is changed,
> the extension will break and no longer crash?
There's not enough stack for me to be sure, it could just be a stale xpti.dat

Comment 5

[[e-mail]]

(but revving the IID should fix that too)

Comment 6

[timeless]

it doesn't really matter. you *must* fix the iid. fix that first and we can investigate other stuff later.

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to comment #3)
> Whoops. I indeed forgot to update the iid. The patch was for bug 464770, btw
> (push went wrong, and comment got lost)
> So this crash is likely caused by an binary extension? If the iid is changed,
> the extension will break and no longer crash?

Yes, the uptick in crashes matches bug 464770 checkin on 20090610. But also  something checked in prior to 20090524031837 - graph @
http://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=nsAString_internal%3A%3ACapacity%28%29&date=&range_value=31&range_unit=days&do_query=1&signature=nsAString_internal%3A%3ACapacity%28%29

Date	Product	Version	Build
2009-06-20 01:57 	Thunderbird	3.0b3pre	20090524031837
2009-06-17 19:02 	Thunderbird	3.0b3pre	20090529032206
2009-06-17 19:01 	Thunderbird	3.0b3pre	20090529032206
2009-06-17 19:01 	Thunderbird	3.0b3pre	20090529032206

did the user install an extension a month after DL the build?

Comment 8

[Mark Banner (:standard8)]

Attachment: Bump uuids

Bump the uuids that were missed. These files haven't been touched since mvl's checkin.

Comment 9

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/00fe804d88fa

The Thunderbird windows builds from today failed (trunk & branch) - so I'm respinning them and hopefully they will be successful and include this fix. The other builds will pick it up tomorrow.

Comment 10

[Wayne Mery (:wsmwk)]

standard8 pointed out on irc ...
 the crashes in this list from the 21st 15:53 to 16:01 http://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=nsAString_internal%3A%3ACapacity%28%29&date=&range_value=31&range_unit=days&do_query=1&signature=nsAString_internal%3A%3ACapacity%28%29 have executable name of shredder.exe 

working theory is "someone has renamed thunderbird.exe to shredder.exe, and they are applying automatic updates - which miss that fact and so they aren't actually updating their executable"