973319 - Firefox 30.0a1 Crash Report [@ XPCVariant::Release() ]

Status: VERIFIED FIXED

(Core :: Networking: Cache, defect)

Description

[Mayank Bansal]

Attachment: about support.txt

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140215030204

Steps to reproduce:

i have OMTC+ new cache + browser.remote.tabs= true.

I opened amazon.in , cicked on my orders. While the page was loading, i opened google chrome, and minimised+maximised Nightly 3-4 times.


Actual results:

crash


Expected results:

no crash.

I dont have reproducible STR

https://crash-stats.mozilla.com/report/index/87d22746-f0ad-4b6d-9798-a53992140216

Comment 1

[Mats Palmgren (inactive)]

The crash looks cache related so maybe "new cache" is the culprit?

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

This is #11 in topcrashers for Firefox 30.0a1 right now, with 300 crashes out of 13087 in the last 7 days.

Comment 3

[Danny O'Brien]

So the range of this bug's spike is from 2014021903 to 2014022503 which is around when new cache was turned on and off for nightly ( Bug 967693 until Bug 975829 ).

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

Oh, it looks like the last crash report was from 20140222, so this is probably fixed now. 

Danny also pointed out it is probably related to meta bug 913806. (Thanks!)

Comment 5

[Robert Kaiser]

If it's related to new cache, then it might well just be disabled and not fixed, and it might be an issue that devs need to look into before turning new cache on permanently.

Comment 6

[Tracy Walker [:tracy]]

I hadn't filed this one because it *did* look as though something else had fixed it.  However, that is not the case.  There are crashes for builds of 20140225 and a couple for 20140226. Currently don't see data for 20140227.

Comment 7

[Honza Bambas (:mayhemer)]

Yep, related to cache2.  Apparently we release the channel on the cache2 IO thread.  This must not happen since the channel may release a lot of other stuff (own callbacks etc.)

This should be simple to fix.

Comment 8

[Honza Bambas (:mayhemer)]

Attachment: v1

the cause of why the channel is not released on the correct thread:
- the final callback (onCacheEntryAvailable) we redirect to the main thread
- but it's executed thanks thread scheduling sooner then we finish CacheEntry::InvokeCallbacks on the IO thread
- hence we finally release the channel on the IO thread

This could actually be considered a critical bug.

Comment 9

[Honza Bambas (:mayhemer)]

(I cannot right now do a try push, but we should do it for this patch before landing)

Comment 10

[Honza Bambas (:mayhemer)]

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=6ba86b56023e

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/caf798d7391a

Comment 12

[u279076]

@mayankleoboy1, are you able to reproduce this crash anymore?

Comment 13

[Mayank Bansal]

Not in a long time.

Comment 14

[u279076]

(In reply to mayankleoboy1 from comment #13)
> Not in a long time.

Thanks!