Closed Bug 700493 Opened 13 years ago Closed 12 years ago

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

Categories

(Core :: Networking, defect)

8 Branch
x86
All
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla15
Tracking Status
firefox12 - ---
firefox14 + verified
firefox15 + verified
firefox-esr10 14+ verified

People

(Reporter: marcia, Assigned: mayhemer)

References

()

Details

(Keywords: crash, reproducible, topcrash, Whiteboard: [startupcrash][STR in bug 740330][Analyzes comment 20])

Crash Data

Attachments

(1 file)

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) yasearch@yandex.ru (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) fe_7.0@nokia.com
     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
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.
Crash Signature: [@ @0x0 | nsXULPrototypeCache::HasData(nsIURI*, int*)] → [@ @0x0 | nsXULPrototypeCache::HasData(nsIURI*, int*)] [@ PR_JoinThread ]
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.
Adding jst - perhaps he can help direct Max to someone that can answer the question in comment 2.
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
Crash Signature: [@ @0x0 | nsXULPrototypeCache::HasData(nsIURI*, int*)] [@ PR_JoinThread ] → [@ @0x0 | nsXULPrototypeCache::HasData(nsIURI*, int*)] [@ PR_JoinThread ] [@ nsXULTemplateBuilder::Uninit(int) ] [@ nsXULTemplateBuilder::Uninit ]
Marcia, is that crash reproducible and a regression?
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?
Keywords: qawanted
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.
Depends on: 716345
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) yasearch@yandex.ru (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) yasearch@yandex.ru (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) yasearch@yandex.ru (Yandex.Bar, https://addons.mozilla.org/addon/3495)
     74% (48/65) vs.   7% (8688/125158) {37964A3C-4EE8-47b1-8321-34DE2C39BA4D} (Спутник @Mail.Ru)
Keywords: topcrash
Summary: Firefox Crash @ @0x0 | nsXULPrototypeCache::HasData(nsIURI*, int*) ] (Correlated to Yandex Bar) → Firefox Crash @ PR_JoinThread or nsXULPrototypeCache::HasData or nsXULTemplateBuilder::Uninit (Correlated to Yandex Bar and Спутник @Mail.Ru)
Whiteboard: startupcrash
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.
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.
biesi says this shouldn't happen, so I think this needs investigation by the networking team.
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Kyle, who on the networking team can we get to look at this?
(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.
Josh, can we get someone to look at this?
Honza - can you look into this?
Assignee: nobody → honzab.moz
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++
Crash Signature: [@ @0x0 | nsXULPrototypeCache::HasData(nsIURI*, int*)] [@ PR_JoinThread ] [@ nsXULTemplateBuilder::Uninit(int) ] [@ nsXULTemplateBuilder::Uninit ] → [@ @0x0 | nsXULPrototypeCache::HasData(nsIURI*, int*)] [@ PR_JoinThread ] [@ PR_JoinThread | mozilla::scache::StartupCache::GetBuffer(char const*, char**, unsigned int*)] [@ PR_JoinThread | mozilla::scache::StartupCache::GetBuffer]
OS: Windows 7 → All
Summary: Firefox Crash @ PR_JoinThread or nsXULPrototypeCache::HasData or nsXULTemplateBuilder::Uninit (Correlated to Yandex Bar and Спутник @Mail.Ru) → Firefox Crash in nsJARChannel::OnStopRequest @ nsXULPrototypeScript::SerializeOutOfLine (Correlated to Yandex Bar and Спутник @Mail.Ru)
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.
Keywords: qawantedreproducible
Whiteboard: startupcrash → [startupcrash][STR in bug 740330]
(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.
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/yasearch@yandex.ru/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?
Status: NEW → ASSIGNED
Whiteboard: [startupcrash][STR in bug 740330] → [startupcrash][STR in bug 740330][Analyzes comment 20]
This is reproducible in Fx12b5, but it hasn't been triaged for that that branch, so I'm requesting tracking.
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.
Attached patch v1Splinter Review
- 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)
Attachment #616533 - Flags: review?(bzbarsky)
Comment on attachment 616533 [details] [diff] [review]
v1

r=me
Attachment #616533 - Flags: review?(bzbarsky) → review+
Attachment #616533 - Flags: approval-mozilla-central?
Comment on attachment 616533 [details] [diff] [review]
v1

[Triage Comment]
Approving for mozilla-central given this is a top crash.
Attachment #616533 - Flags: approval-mozilla-central? → approval-mozilla-central+
https://hg.mozilla.org/mozilla-central/rev/7291d4dee7ec
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
Depends on: 671468
No longer depends on: 671468
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 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:
Attachment #616533 - Flags: approval-mozilla-esr10?
Attachment #616533 - Flags: approval-mozilla-aurora?
Comment on attachment 616533 [details] [diff] [review]
v1

[Triage Comment]
Approved for Aurora 14 and ESR.
Attachment #616533 - Flags: approval-mozilla-esr10?
Attachment #616533 - Flags: approval-mozilla-esr10+
Attachment #616533 - Flags: approval-mozilla-aurora?
Attachment #616533 - Flags: approval-mozilla-aurora+
Comment on attachment 616533 [details] [diff] [review]
v1

sorry, leaving the ESR in nominate since this is 14+. Will approve post-6/5
Attachment #616533 - Flags: approval-mozilla-esr10+ → approval-mozilla-esr10?
Crash Signature: [@ @0x0 | nsXULPrototypeCache::HasData(nsIURI*, int*)] [@ PR_JoinThread ] [@ PR_JoinThread | mozilla::scache::StartupCache::GetBuffer(char const*, char**, unsigned int*)] [@ PR_JoinThread | mozilla::scache::StartupCache::GetBuffer] → [@ @0x0 | nsXULPrototypeCache::HasData(nsIURI*, int*)] [@ @0x0 | nsXULPrototypeCache::HasData(nsIURI*, bool*)] [@ PR_JoinThread ] [@ PR_JoinThread | mozilla::scache::StartupCache::GetBuffer(char const*, char** unsigned int*)] [@ PR_JoinThread | mozill…
Comment on attachment 616533 [details] [diff] [review]
v1

[Triage Comment]
We're in the 14 cycle now, so approving for landing to ESR.
Attachment #616533 - Flags: approval-mozilla-esr10? → approval-mozilla-esr10+
Verified fixed with Firefox 10.0.6esrpre 2012-06-21 using steps from bug 740330.
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?
Keywords: verifyme
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
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.
Status: RESOLVED → VERIFIED
Keywords: verifyme
QA Contact: anthony.s.hughes
(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
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).
Thanks for the follow up, Honza.
You need to log in before you can comment on or make changes to this bug.