Crash in mozilla::net::nsHttpChannel::GetCacheTokenExpirationTime

RESOLVED DUPLICATE of bug 1318759

Status

()

Core
Networking: HTTP
--
critical
RESOLVED DUPLICATE of bug 1318759
2 years ago
a year ago

People

(Reporter: marcia, Assigned: mayhemer)

Tracking

({crash, regression, topcrash})

Trunk
Unspecified
Windows 10
crash, regression, topcrash
Points:
---

Firefox Tracking Flags

(firefox52+ fixed, firefox53+ fixed)

Details

(Whiteboard: [necko-active], crash signature)

This bug was filed from the Socorro interface and is 
report bp-36a56448-8414-47b8-9efc-7373a2161114.
=============================================================

Seen while looking at crash stats - this started in 52 and has moved into 53: http://bit.ly/2ezrLj9

Crashes started with 20161114030203. 

https://hg.mozilla.org/mozilla-central/annotate/155d97b3f8c9/netwerk/protocol/http/nsHttpChannel.cpp mentions some merge conflicts - not sure if that is helpful.
(Assignee)

Comment 1

2 years ago
I remember Dragana doing recently something with suspend/resume.  But the top frame suggests cache issue...
There is bug 1313923, but there is a check so it is not that. And this bug and bug Honza mentioned landed around 3.11.

I will look at the change log around 14.11.
There have been 368 crashes reported with this signature across 77 installations in Nightly 53.0a1 over the past 7 days. It's the #2 browser topcrash for that period.
Here's the regression window between Nov 13 and Nov 14
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b37be3d705d929ee52280051d58cedc70a47626f&tochange=a516c754042c438a5c1499171ca525a980ecb911

I don't see bug 1313923 in that list. The most relevant change I see is bug 1313595. kmckinley, could it have caused this crash?
Flags: needinfo?(kmckinley)
Is it possible if HSTS priming times out and we cancel the channel that the cache entry disappears between checking mCacheEntry and using it? Or do the listeners always run serially?
Flags: needinfo?(kmckinley)
(Assignee)

Comment 6

a year ago
(In reply to Kate McKinley [:kmckinley] from comment #5)
> Is it possible if HSTS priming times out and we cancel the channel that the
> cache entry disappears between checking mCacheEntry and using it? 

This method is AFAIK used only on the main thread, so, no.

> Or do the
> listeners always run serially?

|this| is actually broken (the nsHttpChannel).

According https://crash-stats.mozilla.com/report/index/8eae1648-1148-4650-b705-655b42161122 apparently the static cast to nsHttpChannel is wrong [1], since the channel notifying onstart is actually nsBaseChannel (which has nothing to do with http).

Honestly, I see the same crashes on 20160604131506 (and probably sooner) with the first spike at build id 20161114043454 (no time to crawl in regressions).

There are also more types of crashes with the same top frame that emerged recently:
https://crash-stats.mozilla.com/signature/?_sort=-date&signature=mozilla%3A%3Anet%3A%3AnsHttpChannel%3A%3AGetCacheTokenExpirationTime&date=%3E%3D2016-05-22T13%3A25%3A48.000Z&date=%3C2016-11-22T13%3A25%3A48.000Z#aggregations


[1] https://hg.mozilla.org/mozilla-central/annotate/b7f895c1dc2e/netwerk/protocol/http/HttpChannelParent.cpp#l1090
(Assignee)

Comment 7

a year ago
I suspect this is caused by bug 1313595.
Blocks: 1313595
[Tracking Requested - why for this release]: This is in the top 5 crashes on both Aurora and Nightly.
tracking-firefox52: --- → ?
tracking-firefox53: --- → ?
Keywords: regression, topcrash
tracking as regression/topcrash for 52/53
tracking-firefox52: ? → +
tracking-firefox53: ? → +
I've seen this issue many many times these days on both macOS and Linux.

Not always reproducible but it happens only when I click a hyperlink to open a new tab.

Crash reporter cannot report this on mac because it says:

> We're Sorry
>
> The application had a problem and crashed.
>
> Unfortunately, the crash reporter is unable to submit a report for this crash.
>
> Details: The application didn't leave an application data file.
I can reproduce using a relatively clean profile with addons "NoScript" and "Ghostery" both installed then browser some specific web site, but I cannot find a step to reproduce with a new profile.
(In reply to Gary Chen [:xeonchen] from comment #11)
> I can reproduce using a relatively clean profile with addons "NoScript" and
> "Ghostery" both installed then browser some specific web site, but I cannot
> find a step to reproduce with a new profile.

Indeed, crash-stats has the following correlations:

> (100.0% in signature vs 03.01% overall) Addon "NoScript Security Suite" = true
> (100.0% in signature vs 03.25% overall) Addon "Ghostery" = true

kmckinley, it looks like bug 1313595 may be a red herring; perhaps this new info will help you reproduce?
Flags: needinfo?(kmckinley)
I could not reproduce this on MacOS Linux VM or a Windows 10 VM. Given the sparse information, the only domain I found in the comments for this bug was mxnet.io, which appears to be a crash on a Linux.

The mxnet.io domain is HTTP-only, and after browsing for a while, there doesn't appear to be any mixed-content, so HSTS priming never triggers. I attempted opening links in new tabs and new windows, and did not get a crash. Since this occurs in situations where there is no priming done, I don't believe this is related to bug 1313595 or HSTS priming.

Gary, can you provide steps to reproduce, with a URI that you are able to reliably reproduce this on?
Flags: needinfo?(kmckinley) → needinfo?(xeonchen)
Whiteboard: [necko-active]
(In reply to Kate McKinley [:kmckinley] from comment #13)
> I could not reproduce this on MacOS Linux VM or a Windows 10 VM. Given the
> sparse information, the only domain I found in the comments for this bug was
> mxnet.io, which appears to be a crash on a Linux.
> 
> The mxnet.io domain is HTTP-only, and after browsing for a while, there
> doesn't appear to be any mixed-content, so HSTS priming never triggers. I
> attempted opening links in new tabs and new windows, and did not get a
> crash. Since this occurs in situations where there is no priming done, I
> don't believe this is related to bug 1313595 or HSTS priming.
> 
> Gary, can you provide steps to reproduce, with a URI that you are able to
> reliably reproduce this on?

Sorry for late reply.

The URL I connected to is https://goo.gl/1MKIHI, I cannot reproduce in a clean profile, but if the crash happens, it is always reproducible by the given URL.
Flags: needinfo?(xeonchen)
(Assignee)

Updated

a year ago
Assignee: nobody → honzab.moz
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1318759
Updating tracking flags for the rel health dashboard.
status-firefox52: affected → fixed
status-firefox53: affected → fixed
You need to log in before you can comment on or make changes to this bug.