599126 - Crash in [@ nsConverterOutputStream::WriteString(nsAString_internal const&, int*) ]

Status: RESOLVED WORKSFORME

(Core :: Internationalization, defect)

Description

[Marcia Knous [:marcia]]

Seen while reviewing 3.6.10 crash stats. http://tinyurl.com/2gytfxv links to the crashes, which appear to be all Win XP. Currently ranks as the #15 top crash on 3.6.10 and seems similar to Bug 597260. Most of the comments seem to be in Russian.

Frame 	Module 	Signature [Expand] 	Source
0 		@0x60 	
1 	xul.dll 	nsConverterOutputStream::WriteString 	intl/uconv/src/nsConverterOutputStream.cpp:131
2 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
3 	xul.dll 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:2722
4 	xul.dll 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1740
5 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1360
6 	js3250.dll 	js_Interpret 	js/src/jsops.cpp:2240
7 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1368
8 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1696
9 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:570
10 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
11 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
12 	xul.dll 	nsObserverService::NotifyObservers 	xpcom/ds/nsObserverService.cpp:182
13 	xul.dll 	nsXREDirProvider::DoStartup 	toolkit/xre/nsXREDirProvider.cpp:811
14 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3345
15 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:120
16 	firefox.exe 	__tmainCRTStartup 	obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591
17 	kernel32.dll 	BaseProcessStart

Comment 1

[chris hofmann]

this has moved higher in ranking on 3.6.10 to #4, but it appears to be affecting across all releases.

checking --- nsConverterOutputStream::WriteString.nsAString_internal.const...int.. 20100923-crashdata.csv
found in: 3.6.10 3.6.8 3.6.6 3.6.9 3.6.4 3.6.11pre 3.6.7 4.0b6
release total-crashes
              nsConverterOutputStream::WriteString.nsAString_internal.const...int.. crashes
                         pct.
all     332249  3649    0.0109827
3.6.10  178459  1987    0.0111342
3.6.8   26924   1342    0.049844
3.6.6   6646    211     0.0317484
3.6.9   7769    79      0.0101686
3.6.4   2972    9       0.00302826
3.6.11pr221     8       0.0361991
3.6.7   1195    7       0.00585774
4.0b6   22291   6       0.000269167


os breakdown
nsConverterOutputStream::WriteString.nsAString_internal.const...int..Total 3649
Win5.1  100%


a couple of users put e-mails in public comments

[e-mail]
[e-mail] 

this appears to be happening at startup, and then may block users from starting again.

Correlation to startup or time of session
3649 total crashes for nsConverterOutputStream::WriteString.nsAString_internal.const...int.. on 20100923-crashdata.csv
3590 startup crashes inside 30 sec.
3645 startup crashes inside 3 min.
2832 repeated crashes inside 3 min. of last crash

we should look through the module list for suspicious (maybe malware) .dll's

Comment 2

[chris hofmann]

probably the same as Bug 597260

spike started on sept10.  dip in the middle might be due to soccoro downtime

date     crashes at
         nsConverterOutputStream::WriteString.nsAString_internal.const...int..
20100901 7
20100902 1
20100903 1
20100904 5
20100905 2
20100906 3
20100907 4
20100908 2
20100909 2
20100910 656
20100911 1790
20100912 2554
20100913 3895
20100914 2379
20100915 0
20100916 795
20100917 1892
20100918 2438
20100919 3041
20100920 4502
20100921 3657
20100922 3476
20100923 3649

Comment 3

[chris hofmann]

nothing jumps out on first inspection.  it is interesting that security and ldap libraries are loaded 100% of the time v. 44%

 nsConverterOutputStream::WriteString(nsAString_internal const&, int*)|EXCEPTION_ACCESS_VIOLATION_READ (72 crashes)
    100% (72/72) vs.  44% (3166/7234) lz32.dll
    100% (72/72) vs.  46% (3311/7234) wldap32.dll
    100% (72/72) vs.  49% (3542/7234) iphlpapi.dll
    100% (72/72) vs.  50% (3614/7234) hnetcfg.dll
    100% (72/72) vs.  51% (3672/7234) wshtcpip.dll
    100% (72/72) vs.  63% (4550/7234) comres.dll
    100% (72/72) vs.  64% (4662/7234) ws2help.dll
    100% (72/72) vs.  69% (5018/7234) t2embed.dll
    100% (72/72) vs.  70% (5076/7234) winrnr.dll
    100% (72/72) vs.  70% (5077/7234) brwsrcmp.dll
    100% (72/72) vs.  71% (5172/7234) browserdirprovider.dll
    100% (72/72) vs.  72% (5196/7234) psapi.dll
    100% (72/72) vs.  73% (5263/7234) netapi32.dll
    100% (72/72) vs.  73% (5299/7234) firefox.exe
    100% (72/72) vs.  73% (5300/7234) xpcom.dll
    100% (72/72) vs.  74% (5326/7234) dbghelp.dll
    100% (72/72) vs.  76% (5475/7234) dnsapi.dll
    100% (72/72) vs.  80% (5757/7234) mswsock.dll
    100% (72/72) vs.  86% (6192/7234) secur32.dll
    100% (72/72) vs.  92% (6674/7234) urlmon.dll
    100% (72/72) vs.  94% (6768/7234) crypt32.dll
    100% (72/72) vs.  94% (6771/7234) msasn1.dll
    100% (72/72) vs.  94% (6827/7234) wininet.dll

Comment 4

[timeless]

actually, i'm not sure this is necessarily the same as that one. converteroutputstream is actually in internationalization, and it's a far cry from the xpcom crash.

Note that the xpcom crash is a write to what should be a safe stack variable. this crash is a read from what was hopefully a function address from a method table (of what is likely to be a null object).

Signature	nsConverterOutputStream::WriteString(nsAString_internal const&, int*)
UUID	66896a78-b5b8-4fb9-aad2-85e102100923
Time 	2010-09-23 09:18:00.259763
Uptime	569
Last Crash	12079 seconds (3.4 hours) before submission
Install Age	612876 seconds (1.0 weeks) since version was first installed.
Product	Firefox
Version	3.6.10
Build ID	20100914125854
Branch	1.9.2
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	AuthenticAMD family 15 model 95 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x60
User Comments	
Processor Notes 	WARNING: Json file missing Add-ons
EMCheckCompatibility	False
Related Bugs

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 		@0x60 	
1 	xul.dll 	nsConverterOutputStream::WriteString 	intl/uconv/src/nsConverterOutputStream.cpp:131
2 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
3 	xul.dll 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:2722
4 	xul.dll 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1740
5 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1360
6 	js3250.dll 	js_Interpret 	js/src/jsops.cpp:2240
7 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1368
8 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1696
9 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:570
10 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
11 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
12 	xul.dll 	nsObserverService::NotifyObservers 	xpcom/ds/nsObserverService.cpp:182
13 	xul.dll 	nsXREDirProvider::DoStartup 	toolkit/xre/nsXREDirProvider.cpp:811

125 NS_IMETHODIMP
126 nsConverterOutputStream::WriteString(const nsAString& aString, PRBool* aSuccess)
127 {
128     PRInt32 inLen = aString.Length();
129     nsAString::const_iterator i;
130     aString.BeginReading(i);
131     return Write(inLen, i.get(), aSuccess);
132 }

tails to:

86 NS_IMETHODIMP
87 nsConverterOutputStream::Write(PRUint32 aCount, const PRUnichar* aChars,
88                                PRBool* aSuccess)
89 {

here we ensure mOutStream isn't null (wah, life would be so much easier if this important check was missing, and this class isn't threadsafe, so we can't blame another thread for changing it - darn):
90     if (!mOutStream) {
91         NS_ASSERTION(!mConverter, "Closed streams shouldn't have converters");
92         return NS_BASE_STREAM_CLOSED;
93     }

here we assert mConverter:
94     NS_ASSERTION(mConverter, "Must have a converter when not closed");
95 
96     PRInt32 inLen = aCount;
97 
98     PRInt32 maxLen;

and here we use it:
99     nsresult rv = mConverter->GetMaxLength(aChars, inLen, &maxLen);
100     NS_ENSURE_SUCCESS(rv, rv);

I had hoped that mConverter wasn't null -- hoping that we'd have seen nsConverterOutputStream::Write in the stack trace which we didn't, but I don't like the other choices at all.

102     nsCAutoString buf;
103     buf.SetLength(maxLen);
104     if (buf.Length() != (PRUint32) maxLen)
105         return NS_ERROR_OUT_OF_MEMORY;
106 
107     PRInt32 outLen = maxLen;

we're still using mConverter, this time a different function:
108     rv = mConverter->Convert(aChars, &inLen, buf.BeginWriting(), &outLen);
109     if (NS_FAILED(rv))
110         return rv;
111     if (rv == NS_ERROR_UENC_NOMAPPING) {
112         // Yes, NS_ERROR_UENC_NOMAPPING is a success code
113         return NS_ERROR_LOSS_OF_SIGNIFICANT_DATA;
114     }
115     NS_ASSERTION((PRUint32) inLen == aCount,
116                  "Converter didn't consume all the data!");
117 
118     PRUint32 written;

this is the last method jump available, but we already checked that mOutStream wasn't null :(
119     rv = mOutStream->Write(buf.get(), outLen, &written);
120     *aSuccess = NS_SUCCEEDED(rv) && written == PRUint32(outLen);
121     return rv;
122 
123 }

133 class nsIUnicodeEncoder : public nsISupports
 59 interface nsISupports {
 60   void QueryInterface(in nsIIDRef uuid, 
 62   [noscript, notxpcom] nsrefcnt AddRef();
 63   [noscript, notxpcom] nsrefcnt Release();
179   NS_IMETHOD Convert(const PRUnichar * aSrc, PRInt32 * aSrcLength, 
192   NS_IMETHOD Finish(char * aDest, PRInt32 * aDestLength) = 0;
205   NS_IMETHOD GetMaxLength(const PRUnichar * aSrc, PRInt32 aSrcLength, 
212   NS_IMETHOD Reset() = 0;
219   NS_IMETHOD SetOutputErrorBehavior(PRInt32 aBehavior, 

So, the question is: can 0x60 somehow match up with GetMaxLength, it's the 6th method according to lazy counting. but that means assuming that a method costs x10 in offsets, and they generally shouldn't :(. fwiw this is Windows XP and a 32bit process.

Comment 5

[chris hofmann]

it appears about 90% of users have compatibility checking turned off for this signature.

Comment 6

[Marcia Knous [:marcia]]

1,197 Crash Reports in the last week in this signature for Firefox 4 - all appear to be startup crashes. No comments and the correlation data is not up at the moment.

Comment 7

[Sheila Mooney]

We still have this signature on 8.0 but low volume with 150 crashes in 4 weeks. Removing the top crash key word.

Comment 8

[Wayne Mery (:wsmwk)]

Only two crashes in the past 6 months for all releases, so the original issue is either WFM or morphed.
bp-6440c2d5-98ca-43e2-8c98-cf79c2150305 windows 8