#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
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?
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.
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?
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.
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
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.
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
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*) ]
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
nothing for current versions