1317517 - Crash in mozilla::net::nsHttpChannel::GetCacheTokenExpirationTime

Status: RESOLVED DUPLICATE of bug 1318759

(Core :: Networking: HTTP, defect)

Description

[Marcia Knous [:marcia]]

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.

Comment 1

[Honza Bambas (:mayhemer)]

I remember Dragana doing recently something with suspend/resume.  But the top frame suggests cache issue...

Comment 2

[Dragana Damjanovic [:dragana]]

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.

Comment 3

[Nicholas Nethercote [inactive]]

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.

Comment 4

[Nicholas Nethercote [inactive]]

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?

Comment 5

[Kate McKinley [:kmckinley, :Kate]]

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?

Comment 6

[Honza Bambas (:mayhemer)]

(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

Comment 7

[Honza Bambas (:mayhemer)]

I suspect this is caused by bug 1313595.

Comment 8

[Andrew McCreight [:mccr8]]

[Tracking Requested - why for this release]: This is in the top 5 crashes on both Aurora and Nightly.

Comment 9

[Julien Cristau [:jcristau]]

tracking as regression/topcrash for 52/53

Comment 10

[Gary Chen [:xeonchen]]

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.

Comment 11

[Gary Chen [:xeonchen]]

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.

Comment 12

[Nicholas Nethercote [inactive]]

(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?

Comment 13

[Kate McKinley [:kmckinley, :Kate]]

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?

Comment 14

[Gary Chen [:xeonchen]]

(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.

Comment 16

[Marcia Knous [:marcia]]

Updating tracking flags for the rel health dashboard.