700493 - Firefox Crash in nsJARChannel::OnStopRequest @ nsXULPrototypeScript::SerializeOutOfLine (Correlated to Yandex Bar and Спутник @Mail.Ru)

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is 
report bp-e8773f55-d32e-448b-8a6d-452152111107 .
============================================================= 

Seen while looking at the 7.0 component report. Windows only crash that has 705 Crash Reports in the last week. Fairly high correlation to Yandex Bar.

Correlations:

81% (43/53) vs.   4% (5753/128354) [e-mail] (Yandex.Bar, https://addons.mozilla.org/addon/3495)
     40% (21/53) vs.   4% (5278/128354) {37964A3C-4EE8-47b1-8321-34DE2C39BA4D}
     19% (10/53) vs.   0% (354/128354) [e-mail]
     23% (12/53) vs.  10% (13426/128354) {82AF8DCA-6DE9-405D-BD5E-43525BDAD38A}
     13% (7/53) vs.   5% (6944/128354) {b9db16a4-6edc-47ec-a1f4-b86292ed211d} (Video DownloadHelper, https://addons.mozilla.org/addon/3006)
     17% (9/53) vs.  10% (12509/128354) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865)
      8% (4/53) vs.   2% (1948/128354) {1018e4d6-728f-4b20-ad56-37578a4de76b} (Flagfox, https://addons.mozilla.org/addon/5791)
      8% (4/53) vs.   2% (2035/128354) {19503e42-ca3c-4c27-b1e2-9cdb2170ee34} (FlashGot, https://addons.mozilla.org/addon/220)


Frame 	Module 	Signature [Expand] 	Source
0 		@0x0 	
1 	xul.dll 	nsXULPrototypeCache::HasData 	content/xul/document/src/nsXULPrototypeCache.cpp:575
2 	xul.dll 	nsCOMPtr_base::~nsCOMPtr_base 	obj-firefox/dist/include/nsAutoPtr.h:969
3 	xul.dll 	nsStandardURL::SchemeIs 	netwerk/base/src/nsStandardURL.cpp:1752
4 	xul.dll 	nsXULPrototypeScript::SerializeOutOfLine 	content/xul/content/src/nsXULElement.cpp:2979
5 	xul.dll 	nsXULDocument::OnStreamComplete 	content/xul/document/src/nsXULDocument.cpp:3584
6 	xul.dll 	nsStreamLoader::OnStopRequest 	netwerk/base/src/nsStreamLoader.cpp:125
7 	xul.dll 	nsJARChannel::OnStopRequest 	modules/libjar/nsJARChannel.cpp:903
8 	xul.dll 	nsInputStreamPump::OnStateStop 	netwerk/base/src/nsInputStreamPump.cpp:578
9 	xul.dll 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:403
10 	xul.dll 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:114
11 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:631
12 	xul.dll 	nsThread::GetObserver 	xpcom/threads/nsThread.cpp:705
13 	xul.dll 	nsThread::Shutdown 	xpcom/threads/nsThread.cpp:494
14 	xul.dll 	nsHtml5ParserThreadTerminator::Observe 	parser/html/nsHtml5Module.cpp:134
15 	xul.dll 	nsObserverList::NotifyObservers 	xpcom/ds/nsObserverList.cpp:130
16 	xul.dll 	nsObserverService::NotifyObservers 	xpcom/ds/nsObserverService.cpp:182
17 	xul.dll 	mozilla::ShutdownXPCOM 	xpcom/build/nsXPComInit.cpp:604
18 	xul.dll 	ScopedXPCOMStartup::~ScopedXPCOMStartup 	toolkit/xre/nsAppRunner.cpp:1083
19 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3574
20 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:107
21 	firefox.exe 	firefox.exe@0x4043 	
22 	firefox.exe 	_RTC_Initialize 	
23 	mozcrt19.dll 	_initterm 	obj-firefox/memory/jemalloc/crtsrc/crt0dat.c:852
24 	firefox.exe 	firefox.exe@0x2087 	
25 	ntdll.dll 	WinSqmSetIfMaxDWORD 	
26 	ntdll.dll 	_RtlUserThreadStart 	
27 	firefox.exe 	firefox.exe@0x1cef 	
28 	firefox.exe 	firefox.exe@0x1cef

Comment 1

[Marcia Knous [:marcia]]

Adding [@ PR_JoinThread ] as it appears to be related to Yandex bar. Showing up as a Mac and Windows crash now. 1,344 Crash Reports across all Firefox versions up to trunk in the last week.

Comment 2

[Max]

Judging by description here the bug is somehow related to xul overlays. Y.Bar generates main window overlay dynamically and serves it through a custom protocol.
Is there anything Yandex.Bar devs (namely me and Danil Ivanov) can do to help identify the problem? We can provide additional details if there's a need.

Comment 3

[Marcia Knous [:marcia]]

Adding jst - perhaps he can help direct Max to someone that can answer the question in comment 2.

Comment 4

[Marcia Knous [:marcia]]

I noticed two other signatures today related to xul templates that seem to have a correlation to Yandex as well:

[@ nsXULTemplateBuilder::Uninit(int) ] Windows Signature
[@ nsXULTemplateBuilder::Uninit ] Mac and Linux Signature

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Marcia, is that crash reproducible and a regression?

Comment 6

[Marcia Knous [:marcia]]

Haven't tried to reproduce yet. Adding qawanted to get some possible STR. I will try to reproduce when I have some more time.

(In reply to Henrik Skupin (:whimboo) from comment #5)
> Marcia, is that crash reproducible and a regression?

Comment 7

[Marcia Knous [:marcia]]

8.0.1 had 46 crashes in nsXULTemplateBuilder::Uninit  - the 9.0 betas had low volume in this signature.

8.0 and 8.0.1 had 358 crashes in nsXULTemplateBuilder::Uninit(int), but the most we have had in a beta is 27 crashes.

PR_JoinThread had 3040 crashes in 8.0 and 8.0.1, but the most crashes in a 9.0 beta were 173.

We should watch this for Firefox 9 and see what happens regarding volume. I am running in XP with this toolbar today so I will see if I can reproduce the crash.

Comment 8

[Scoobidiver (away)]

With combined signatures, it's #22 top crasher.
Depending on the crash signature, 75-85% of crashes happen within one minute.

Here are the latest correlations on 9.0.1:
* PR_JoinThread|EXCEPTION_ACCESS_VIOLATION_READ (336 crashes)
     81% (273/336) vs.   7% (8837/125158) [e-mail] (Yandex.Bar, https://addons.mozilla.org/addon/3495)
     73% (246/336) vs.   7% (8688/125158) {37964A3C-4EE8-47b1-8321-34DE2C39BA4D} (Спутник @Mail.Ru)
* @0x0 | nsXULPrototypeCache::HasData(nsIURI*, int*)|EXCEPTION_ACCESS_VIOLATION_EXEC (140 crashes)
     96% (135/140) vs.   7% (8837/125158) [e-mail] (Yandex.Bar, https://addons.mozilla.org/addon/3495)
     85% (119/140) vs.   7% (8688/125158) {37964A3C-4EE8-47b1-8321-34DE2C39BA4D} (Спутник @Mail.Ru)
* nsXULTemplateBuilder::Uninit(int)|EXCEPTION_ACCESS_VIOLATION_READ (65 crashes)
     83% (54/65) vs.   7% (8837/125158) [e-mail] (Yandex.Bar, https://addons.mozilla.org/addon/3495)
     74% (48/65) vs.   7% (8688/125158) {37964A3C-4EE8-47b1-8321-34DE2C39BA4D} (Спутник @Mail.Ru)

Comment 9

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

So, what's happening here is that we're trying to do startup cache stuff during XPCOM shutdown, but the startup cache has already gone away (it goes away right before xpcom-shutdown-threads, which is the observer notification we're firing).

The obvious question here is why we're still getting OnInputStreamReady events at this point.

Comment 10

[Benjamin Smedberg]

Yes, I think that's the question. I think that necko really ought to be processing/cancelling all pending streams when we hit profile-before-change and absolutely when we hit xpcom-shutdown, both of which happen well before this stacktrace.

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

biesi says this shouldn't happen, so I think this needs investigation by the networking team.

Comment 12

[Sheila Mooney]

Kyle, who on the networking team can we get to look at this?

Comment 13

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Sheila Mooney from comment #12)
> Kyle, who on the networking team can we get to look at this?

I don't know, which is why I CCd Josh who manages that team.

Comment 14

[Sheila Mooney]

Josh, can we get someone to look at this?

Comment 15

[Josh Aas]

Honza - can you look into this?

Comment 16

[Honza Bambas (:mayhemer)]

Theory (unconfirmed):
- AFAIK, a channel can be canceled before shutdown only when it is in a loadgroup ; I don't see a different way nsJARChannel to cancel at shutdown
- I checked in the debugger we open some nsJARChannels w/o a load group (see [1])
- Such channel may live past the cache shutdown


[1]
NewImageChannel!imgLoader.cpp doesn't set load group on the channel:

http://hg.mozilla.org/mozilla-central/annotate/453d5c733caa/image/src/imgLoader.cpp#l541

nsJARChannel->mLoadGroup is null.

 	xul.dll!nsJARChannel::AsyncOpen(nsIStreamListener * listener=0x08317828, nsISupports * ctx=0x00000000)  Line 778	C++
>	xul.dll!imgLoader::ValidateRequestWithNewChannel(imgRequest * request=0x0953d728, nsIURI * aURI=0x0a2850b0, nsIURI * aInitialDocumentURI=0x0744f8b0, nsIURI * aReferrerURI=0x0744f8b0, nsILoadGroup * aLoadGroup=0x084aca60, imgIDecoderObserver * aObserver=0x074344b0, nsISupports * aCX=0x0ead0760, unsigned int aLoadFlags=0, imgIRequest * aExistingRequest=0x00000000, imgIRequest * * aProxyRequest=0x074344b4, nsIChannelPolicy * aPolicy=0x00000000, nsIPrincipal * aLoadingPrincipal=0x058aa9f0, int aCORSMode=1)  Line 1319 + 0x24 bytes	C++
 	xul.dll!imgLoader::ValidateEntry(imgCacheEntry * aEntry=0x0e3a8890, nsIURI * aURI=0x0a2850b0, nsIURI * aInitialDocumentURI=0x0744f8b0, nsIURI * aReferrerURI=0x0744f8b0, nsILoadGroup * aLoadGroup=0x084aca60, imgIDecoderObserver * aObserver=0x074344b0, nsISupports * aCX=0x0ead0760, unsigned int aLoadFlags=0, bool aCanMakeNewChannel=true, imgIRequest * aExistingRequest=0x00000000, imgIRequest * * aProxyRequest=0x074344b4, nsIChannelPolicy * aPolicy=0x00000000, nsIPrincipal * aLoadingPrincipal=0x058aa9f0, int aCORSMode=1)  Line 1439 + 0x44 bytes	C++
 	xul.dll!imgLoader::LoadImage(nsIURI * aURI=0x0a2850b0, nsIURI * aInitialDocumentURI=0x0744f8b0, nsIURI * aReferrerURI=0x0744f8b0, nsIPrincipal * aLoadingPrincipal=0x058aa9f0, nsILoadGroup * aLoadGroup=0x084aca60, imgIDecoderObserver * aObserver=0x074344b0, nsISupports * aCX=0x0ead0760, unsigned int aLoadFlags=0, nsISupports * aCacheKey=0x00000000, imgIRequest * aRequest=0x00000000, nsIChannelPolicy * aPolicy=0x00000000, imgIRequest * * _retval=0x074344b4)  Line 1646 + 0x49 bytes	C++
 	xul.dll!nsContentUtils::LoadImage(nsIURI * aURI=0x0a2850b0, nsIDocument * aLoadingDocument=0x0ead0760, nsIPrincipal * aLoadingPrincipal=0x058aa9f0, nsIURI * aReferrer=0x0744f8b0, imgIDecoderObserver * aObserver=0x074344b0, int aLoadFlags=0, imgIRequest * * aRequest=0x074344b4)  Line 2617 + 0x44 bytes	C++
 	xul.dll!nsImageLoadingContent::LoadImage(nsIURI * aNewURI=0x0a2850b0, bool aForce=false, bool aNotify=true, nsIDocument * aDocument=0x0ead0760, unsigned int aLoadFlags=0)  Line 791 + 0x3f bytes	C++
 	xul.dll!nsImageLoadingContent::LoadImage(const nsAString_internal & aNewURI={...}, bool aForce=false, bool aNotify=true)  Line 708 + 0x21 bytes	C++
 	xul.dll!nsHTMLImageElement::MaybeLoadImage()  Line 567 + 0x46 bytes	C++

Comment 18

[Simona Badau, Desktop QA]

Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0

Firefox 12 beta 5 crashed having Yandex bar installed.
https://crash-stats.mozilla.com/report/index/bp-b5143dc9-64a1-4451-8abf-53f5d2120412

I reproduced the crash using the steps from Bug 740330.

Comment 19

[Honza Bambas (:mayhemer)]

(In reply to Simona B [QA] from comment #18)
> Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0
> 
> Firefox 12 beta 5 crashed having Yandex bar installed.
> https://crash-stats.mozilla.com/report/index/bp-b5143dc9-64a1-4451-8abf-
> 53f5d2120412
> 
> I reproduced the crash using the steps from Bug 740330.

Going to check on this.  Thanks for the report Simona.

Comment 20

[Honza Bambas (:mayhemer)]

Using steps from Bug 740330 I'm getting failure of this assertion, after step 4:
https://hg.mozilla.org/releases/mozilla-beta/annotate/e6be81269d27/startupcache/StartupCache.cpp#l346

id = "xulcache/C:/Mozilla/profiles/FX/extensions/[e-mail]/chrome/yasearch.jar/content/custombar/overlay/browser.xul"

but Fx doesn't crash it self.  It's a current mozilla-beta debug build.


 	xul.dll!mozilla::scache::StartupCache::PutBuffer(const char * id=0x09c234f0, const char * inbuf=0x09a92c48, unsigned int len=0x00000399)  Line 346 + 0x21 bytes	C++
 	xul.dll!nsXULPrototypeCache::FinishOutputStream(nsIURI * uri=0x08330d60)  Line 509 + 0x21 bytes	C++
 	xul.dll!nsXULPrototypeCache::WritePrototype(nsXULPrototypeDocument * aPrototypeDocument=0x09d3e090)  Line 423	C++
 	xul.dll!nsXULDocument::EndLoad()  Line 598	C++
 	xul.dll!XULContentSinkImpl::DidBuildModel(bool aTerminated=false)  Line 279	C++
 	xul.dll!nsParser::DidBuildModel(unsigned int anErrorCode=0x00000000)  Line 998 + 0x21 bytes	C++
 	xul.dll!nsParser::ResumeParse(bool allowIteration=true, bool aIsFinalChunk=true, bool aCanInterrupt=true)  Line 1633	C++
 	xul.dll!nsParser::OnStopRequest(nsIRequest * request=0x09cef6e0, nsISupports * aContext=0x00000000, unsigned int status=0x00000000)  Line 2196 + 0x1a bytes	C++
>	xul.dll!nsJARChannel::OnStopRequest(nsIRequest * req=0x09f684d0, nsISupports * ctx=0x00000000, unsigned int status=0x00000000)  Line 925	C++

First entry write is done with (I believe) the same stack, nsJARChannel belongs to some file from test pilot.  Second entry write is from finish load of the yandex browser.xul file which the entry (according my poor knowledge of startup cache and the parser) belongs to.



I can see we are loading channels after docshell of the document has been destroyed:

 	xul.dll!nsJARChannel::Init(nsIURI * uri=0x0826fbd8)  Line 288	C++
 	xul.dll!nsJARProtocolHandler::NewChannel(nsIURI * uri=0x0826fbd8, nsIChannel * * result=0x002ccef8)  Line 183 + 0xc bytes	C++
 	xul.dll!nsIOService::NewChannelFromURIWithProxyFlags(nsIURI * aURI=0x0826fbd8, nsIURI * aProxyURI=0x00000000, unsigned int proxyFlags=0x00000000, nsIChannel * * result=0x002ccef8)  Line 665 + 0x2a bytes	C++
 	xul.dll!nsIOService::NewChannelFromURI(nsIURI * aURI=0x0826fbd8, nsIChannel * * result=0x002ccef8)  Line 610	C++
 	xul.dll!nsChromeProtocolHandler::NewChannel(nsIURI * aURI=0x08330740, nsIChannel * * aResult=0x002cd0b0)  Line 196 + 0x46 bytes	C++
 	xul.dll!nsIOService::NewChannelFromURIWithProxyFlags(nsIURI * aURI=0x08330740, nsIURI * aProxyURI=0x00000000, unsigned int proxyFlags=0x00000000, nsIChannel * * result=0x002cd0b0)  Line 665 + 0x2a bytes	C++
 	xul.dll!nsIOService::NewChannelFromURI(nsIURI * aURI=0x08330740, nsIChannel * * result=0x002cd0b0)  Line 610	C++
 	xul.dll!NS_NewChannel(nsIChannel * * result=0x002cd130, nsIURI * uri=0x08330740, nsIIOService * ioService=0x01e9cd30, nsILoadGroup * loadGroup=0x09a1dbf8, nsIInterfaceRequestor * callbacks=0x00000000, unsigned int loadFlags=0x00000000, nsIChannelPolicy * channelPolicy=0x00000000)  Line 226 + 0x2a bytes	C++
>	xul.dll!nsXULDocument::LoadOverlayInternal(nsIURI * aURI=0x08330740, bool aIsDynamic=false, bool * aShouldReturn=0x002cd293, bool * aFailureFromContent=0x002cd28b)  Line 2770 + 0x35 bytes	C++
 	xul.dll!nsXULDocument::ResumeWalk()  Line 3080 + 0x1e bytes	C++
 	xul.dll!nsXULDocument::OnPrototypeLoadDone(bool aResumeWalk=true)  Line 653 + 0xe bytes	C++
 	xul.dll!nsXULDocument::EndLoad()  Line 637	C++
 	xul.dll!XULContentSinkImpl::DidBuildModel(bool aTerminated=false)  Line 279	C++
 	xul.dll!nsParser::DidBuildModel(unsigned int anErrorCode=0x00000000)  Line 998 + 0x21 bytes	C++
 	xul.dll!nsParser::ResumeParse(bool allowIteration=true, bool aIsFinalChunk=true, bool aCanInterrupt=true)  Line 1633	C++
 	xul.dll!nsParser::OnStopRequest(nsIRequest * request=0x0824c790, nsISupports * aContext=0x00000000, unsigned int status=0x00000000)  Line 2196 + 0x1a bytes	C++
 	xul.dll!nsBaseChannel::OnStopRequest(nsIRequest * request=0x087dff40, nsISupports * ctxt=0x00000000, unsigned int status=0x00000000)  Line 746	C++
 	xul.dll!nsInputStreamPump::OnStateStop()  Line 584	C++
 	xul.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream=0x0824c4d0)  Line 405 + 0xb bytes	C++
 	xul.dll!nsInputStreamReadyEvent::Run()  Line 115	C++


nsXULDocument.mDocumentLoadGroup is from a docshell that had already been destroyed.  Hence we don't cancel the new channels since the load group is no longer driven by anyone.  mIsGoingAway of the document is true.  Maybe check this property and stop the parser?  Or should the parser be stopped when the docshell goes away?

Comment 21

[juan becerra [:juanb]]

This is reproducible in Fx12b5, but it hasn't been triaged for that that branch, so I'm requesting tracking.

Comment 22

[Alex Keybl [:akeybl]]

Thanks for bringing this to our attention, but since this isn't a new regression and doesn't appear to have gotten any worse, no need to track for FF12 specifically.

Comment 23

[Honza Bambas (:mayhemer)]

Attachment: v1

- when the document is after its destruction, don't allow any new channels to open
- this prevents this actually shutdown crash (this bug is marked as startup because it restarts shortly after start up)

Comment 24

[Honza Bambas (:mayhemer)]

Comment on attachment 616533 [details] [diff] [review]
v1

- also prevents the assertion failure at https://hg.mozilla.org/releases/mozilla-beta/annotate/e6be81269d27/startupcache/StartupCache.cpp#l346

Comment 25

[Honza Bambas (:mayhemer)]

https://tbpl.mozilla.org/?tree=Try&rev=709574eae66c

Comment 26

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 616533 [details] [diff] [review]
v1

r=me

Comment 27

[Alex Keybl [:akeybl]]

Comment on attachment 616533 [details] [diff] [review]
v1

[Triage Comment]
Approving for mozilla-central given this is a top crash.

Comment 28

[Honza Bambas (:mayhemer)]

Comment on attachment 616533 [details] [diff] [review]
v1

https://hg.mozilla.org/integration/mozilla-inbound/rev/7291d4dee7ec

Comment 29

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

https://hg.mozilla.org/mozilla-central/rev/7291d4dee7ec

Comment 30

[Scoobidiver (away)]

It's #2 top crasher in 10.0.4 ESR.

One comment says: "I am installing the enterprise version at IBM for first time (after having used firefox here for years). this error is the first message I receved after selecting addons"

Comment 31

[Honza Bambas (:mayhemer)]

Comment on attachment 616533 [details] [diff] [review]
v1

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: 
Fix Landed on Version:
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch: 

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch:

Comment 32

[Alex Keybl [:akeybl]]

Comment on attachment 616533 [details] [diff] [review]
v1

[Triage Comment]
Approved for Aurora 14 and ESR.

Comment 33

[Alex Keybl [:akeybl]]

Comment on attachment 616533 [details] [diff] [review]
v1

sorry, leaving the ESR in nominate since this is 14+. Will approve post-6/5

Comment 34

[Honza Bambas (:mayhemer)]

Comment on attachment 616533 [details] [diff] [review]
v1

https://hg.mozilla.org/releases/mozilla-aurora/rev/efe05056199f

Comment 36

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 616533 [details] [diff] [review]
v1

[Triage Comment]
We're in the 14 cycle now, so approving for landing to ESR.

Comment 37

[Honza Bambas (:mayhemer)]

Comment on attachment 616533 [details] [diff] [review]
v1

https://hg.mozilla.org/releases/mozilla-esr10/rev/ecf58ec548b5

Comment 38

[u279076]

Verified fixed with Firefox 10.0.6esrpre 2012-06-21 using steps from bug 740330.

Comment 39

[Simona Badau, Desktop QA]

When trying to verify this fix I've noticed several crash reports In Socorro on Firefox 14.0.1, Firefox 15 beta and Firefox 16 having the crash signatures affiliated  with this bug. Firefox 15 beta 3 does not crash when using the steps from Bug 740330.

The crash reports for Firefox 14, Firefox 15 beta and Firefox 16 are:
[@ PR_JoinThread ]: 
https://crash-stats.mozilla.com/report/index/f5a1a7e2-2e03-4873-99e9-78ef22120805
More reports with this signature: http://bit.ly/MIIcBA

[@ PR_JoinThread | mozilla::scache::StartupCache::GetBuffer(char const*, char**, unsigned int*)]:
https://crash-stats.mozilla.com/report/index/a0fe66e7-8b36-432c-aa60-9b46a2120806
More reports with this signature: http://bit.ly/QEWfhq

[@ PR_JoinThread | mozilla::scache::StartupCache::GetBuffer]:
https://crash-stats.mozilla.com/report/index/17383d76-bd13-48a5-8961-5e4e22120803
More reports with this signature: http://bit.ly/R9vVtf

[@ PL_DHashTableOperate | mozilla::scache::StartupCache::GetBuffer(char const*, char**, unsigned int*)]:
https://crash-stats.mozilla.com/report/index/5c6cf2c3-e31c-4039-b8f3-49f002120731
More reports with this signature: http://bit.ly/NwrGmS

Are this crashes related to this bug?

Comment 40

[Simona Badau, Desktop QA]

Honza, can you please take a look at the crashes mentioned in Comment 39? I need to know if these crashes are related to this bug so that I can mark it as verified. Thanks

Comment 41

[u279076]

Marking this verified since I can't reproduce this crash in Firefox 14.0.1 and 15.0 with the steps from bug 740330. The crashes could possibly be related to this bug but I don't have the expertise to make that call. Whether they are nor not, I would suspect that those should be filed in new bugs marked dependent of this one.

Honza, please advise.

Comment 42

[u279076]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #41)
> The crashes could possibly be related to this bug

Sorry, this should read:
> The crashes Simona reported in comment 39 could possibly be related to this bug

Comment 43

[Honza Bambas (:mayhemer)]

Anthony, sorry for delayed response, this became buried among other stuff in my inbox.

Looks like bug 806175 has very similar stack trace, and is related.  I commented on that bug.  It indicates there is still some place we open channels a way those won't get canceled soon enough.

I consider this bug fixed and verified according the STR that helped me to analyze it (from bug 740330).

Comment 44

[u279076]

Thanks for the follow up, Honza.