538795 - Firefox 3.6 RC1 Crash [@ nsJAR::GetInputStream(char const*, nsIInputStream**) ]

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[chris hofmann]

#3 top crash for 3.6 rc1 after about a day of wider spread testing.

the 99 crashes that we have look suspicious.  all are on Windows NT 5.1.2600 Service Pack 2 and came in during a 1 hour blast so this could be one or a few people.

stack looks like

http://crash-stats.mozilla.com/report/index/4944a32f-da5f-4ca1-8757-60c682100109

Frame  	Module  	Signature [Expand]  	Source
0 		@0x501b7010 	
1 	xul.dll 	nsJAR::GetInputStream 	modules/libjar/nsJAR.cpp:316
2 	xul.dll 	nsJARInputThunk::EnsureJarStream 	modules/libjar/nsJARChannel.cpp:166
3 	xul.dll 	nsJARChannel::Open 	modules/libjar/nsJARChannel.cpp:668
4 	xul.dll 	nsJARChannel::Open 	modules/libjar/nsJARChannel.cpp:676
5 	xul.dll 	AppendUTF8toUTF16 	xpcom/string/src/nsReadableUtils.cpp:265
6 	xul.dll 	nsJARInputThunk::Release 	intl/strres/src/nsStringBundle.cpp:246
7 	xul.dll 	AppendUTF8toUTF16 	xpcom/string/src/nsReadableUtils.cpp:318
8 	xul.dll 	ProfileLockedDialog 	toolkit/xre/nsAppRunner.cpp:1789
9 	xul.dll 	nsProfileLock::Lock 	obj-firefox/toolkit/profile/src/nsProfileLock.cpp:449
10 	mozcrt19.dll 	free 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:6017
11 	xul.dll 	nsToolkitProfileLock::Release 	toolkit/profile/src/nsToolkitProfileService.cpp:291
12 	xul.dll 	nsCOMPtr_base::~nsCOMPtr_base 	obj-firefox/dist/include/nsAutoPtr.h:956
13 	xul.dll 	SelectProfile 	
14 	mozcrt19.dll 	arena_dalloc_small 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4129
15 	mozcrt19.dll 	huge_ralloc 	
16 		@0x83c000 	
17 	mozcrt19.dll 	__lock_fhandle 	obj-firefox/memory/jemalloc/crtsrc/osfinfo.c:464
18 	mozcrt19.dll 	_close_nolock 	obj-firefox/memory/jemalloc/crtsrc/close.c:101
19 	mozcrt19.dll 	_close 	obj-firefox/memory/jemalloc/crtsrc/close.c:61

more reports at http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=nsJAR%3A%3AGetInputStream%28char%20const*%2C%20nsIInputStream**%29&version=Firefox%3A3.6

not much to start the investigation with.  no user comments.
looks very close to start up.

could this be a possible regresssion from Bug 511754  - make nsZipItems point at ZipCentral references to mmapped jar area r=tglek  http://hg.mozilla.org/releases/mozilla-1.9.2/log/672df9e9c441/modules/libjar/nsJAR.cpp  

looks like it was landed on 1.9.2 since beta 5.

 Taras Glek (:taras)      2009-12-04 09:41:56 PST

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/ebe315caa591

Comment 1

[(dormant account)]

Chris, I'm a bit confused by this stack. Why is AppendUTF8toUTF16 calling jar stuff and why does it appear twice? is this a common crashserver artifact?

Comment 2

[(dormant account)]

Alfred, any idea on how nsJARInputThunk::Release can call nsJARChannel::Open? I don't see how that's even plausible.

Unless I'm missing something this backtraces isn't possible. My best guess at the moment is that this is bug 536021(which needs landing on 192) + a bogus stack.

Comment 3

[Alfred Kayser]

AppendUTF8toUTF16 is called twice, because the first is an overloaded version, that converts a char * to CString (using nsDependentCString).
Somewhere in here, it seems to release the stream handle, causing to release the jar input trunk, etc...
Looks like that a StringBundle is read from a jar entry, and then processed, but during the processing the handle is closed, making the reference to the memory pointed to incorrect?
Seems like a race condition issue...

Note: the bundle is:
chrome://mozapps/locale/profile/profileSelection.properties
which is packaged into en-US.jar (in the US version).

Note: Bug 536021 is dup'ed to bug 510844. From the latter, the patch landed on 192 on 2009-12-04.

But possibly bug 536911 is the cause here?

And may be bug 537165 is related?

Comment 4

[chris hofmann]

as far as I can tell this signature wasn't present in any of the previous 3.6 betas.   

3.6 rc1 rank has dropped to #31 as other crashes have risen around it.

Comment 5

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

Neither bug 536911 nor 537165 landed on mozilla-1.9.2 from what I can tell, so I don't think those are the cause. Did you mean that potentially bug 510844 is the cause? That was fixed in beta 5, though, so I'd expect to have seen those crash stacks appear in that release, not just in RC1.

The list of things fixed in RC1: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20status1.9.2%3Afinal - nothing there is obvious.

Best guesses:

Bug 538642 -  The FPU exception handler should work on Windows (conflicts with breakpad, bug 533035 not actually fixed)

Bug 492197 -  password manager is extremely slow at reencrypting base64-encoded signons

Bug 529773 -  nsProtocolProxyService::PrefsChanged / nsProtocolProxyService::Resolve_Internal don't behave cleanly when do_GetService(NS_SYSTEMPROXYSETTINGS_CONTRACTID) fails

Comment 6

[Benjamin Smedberg]

This is under SelectProfile, which means that we're not using the standard profile mechanism for fastload and compreg invalidation: it's likely that this is specific to the profile-manager, and possibly a readonly install directory or crash-on-upgrade.

Comment 7

[chris hofmann]

the spike that drove this to #31 seems to have subsided

date nsJAR::GetInputStreamcrashes
20100101-crashdata 5 nsJAR::GetInputStream
20100102-crashdata 2 nsJAR::GetInputStream
20100103-crashdata 0 nsJAR::GetInputStream
20100104-crashdata 7 nsJAR::GetInputStream
20100105-crashdata 0 nsJAR::GetInputStream
20100106-crashdata 5 nsJAR::GetInputStream
20100107-crashdata 3 nsJAR::GetInputStream
20100108-crashdata 2 nsJAR::GetInputStream
20100109-crashdata 104 nsJAR::GetInputStream
20100110-crashdata 2 nsJAR::GetInputStream
20100111-crashdata 2 nsJAR::GetInputStream
20100112-crashdata 1 nsJAR::GetInputStream
20100113-crashdata 0 nsJAR::GetInputStream

Comment 8

[Alfred Kayser]

To be more specific, they are all on Jan 9, with the latest build id: 20100105212446. So one can sort of assume that around 5 Jan, the issue has been fixed...

Probably fixed by Bug 536911 -  crash [@ memcpy | nsJARInputStream::Read(char*, unsigned int, unsigned int*) ]

Comment 9

[Wayne Mery (:wsmwk)]

Is there reason to believe this is gone on trunk? ...

(In reply to comment #8)
> To be more specific, they are all on Jan 9, with the latest build id:
> 20100105212446. So one can sort of assume that around 5 Jan, the issue has been
> fixed...
> 
> Probably fixed by Bug 536911 -  crash [@ memcpy | nsJARInputStream::Read(char*,
> unsigned int, unsigned int*) ]

because although Bug 536911 is fixed in 3.6.4, nsJAR::GetInputStream(char const*, nsIInputStream**) continues. for example ...
bp-d04d7f69-3026-4f6f-a7c3-ae4a32100723 3.6.6
bp-6e714eb2-5535-4afe-9973-cc6c72100731 3.6.8
bp-3e0380a0-c891-469b-8101-b75a32101226 3.6.13
0		@0x872ef708	
1	xul.dll	nsJAR::GetInputStream	modules/libjar/nsJAR.cpp:316
2	xul.dll	nsJARInputThunk::EnsureJarStream	modules/libjar/nsJARChannel.cpp:166
3	xul.dll	nsJARInputThunk::Read	modules/libjar/nsJARChannel.cpp:204
4	xul.dll	nsInputStreamTransport::Read	netwerk/base/src/nsStreamTransportService.cpp:233
5	xul.dll	nsStreamCopierOB::FillOutputBuffer	xpcom/io/nsStreamUtils.cpp:566
6	xul.dll	nsPipeOutputStream::WriteSegments	xpcom/io/nsPipe3.cpp:1137

there are no matching trunk examples - but the crash rate in 3.6.x is so low that it's not surprising I think to not find trunk reports. there are stacks like bp-36d52db6-7f56-4cea-8f06-7cefa2101113, bug stack is different

Comment 10

[Wayne Mery (:wsmwk)]

nothing for current versions