Firefox forgets how to network after trying to load a treeherder page

RESOLVED DUPLICATE of bug 1279246

Status

()

Core
Networking: Cache
--
critical
RESOLVED DUPLICATE of bug 1279246
a year ago
a year ago

People

(Reporter: chutten, Assigned: michal)

Tracking

({hang})

49 Branch
x86_64
Windows 10
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-active])

Attachments

(2 attachments)

2.99 MB, application/x-7z-compressed
Details
1.17 MB, application/x-7z-compressed
Details
(Reporter)

Description

a year ago
Firefox 49.0b3 on Windows 10, Anniversary Update

If I open a treeherder link for a trybuild (e.g. [1]), my browser (previously behaving normally) forgets how to talk to networks. It just sits there. Established connections _appear_ to work (send email in GMail for a short time), but opening a new tab to try to go just about anywhere (twitter, wikimo, firefox.com) will just sit and spin.

Plus, when I kill my browser to restart it, I need to wait longer than a few seconds (perhaps a couple minutes, I got bored) for my profile to be available.

It has done this thrice and appears to be reproducible for me as:

1: Start loading [1] in a tab
2: Try to load just about anything else in another tab, with or without the tab from 1: open.
3: Shutdown Firefox because it isn't as helpful when it can't talk to other resources
4: Try to restart Firefox occasionally over the next couple of minutes, waiting for the profile to be released.

[1]: https://treeherder.mozilla.org/#/jobs?repo=try&revision=83f22bd2efe0
Chris, can you please provide a log as described at [1]?
Was this reproducible also in Win10 10586 (the pre-anniversary update version)?

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Thanks.
Flags: needinfo?(chutten)
(Reporter)

Comment 2

a year ago
Created attachment 8781568 [details]
log.7z

I didn't notice it before the Anniversary Update, but then again I didn't notice it until beta 49 either. Last week I had more meeting than trybuilds, so my datapoints are rather sparse :S

Here's one of the crashes that gets logged when I try to kill Firefox and have to wait: https://crash-stats.mozilla.com/report/index/bp-22ad436a-7e5c-4d5f-8f23-d878b2160816

(The crash dialogs were popping under other windows so I didn't see them until later)
Flags: needinfo?(chutten)
Oh, it's an HTTP cache bug.

Michal, this is hang in CacheFileAutoLock.  Please take a look ASAP.  Thanks.
Flags: needinfo?(michal.novotny)
Severity: normal → critical
Component: Networking → Networking: Cache
Flags: needinfo?(michal.novotny)
Keywords: hang
Whiteboard: [necko-active]
Assignee: nobody → michal.novotny
(Assignee)

Comment 4

a year ago
Chris could you please provide a log with following modules?

NSPR_LOG_MODULES=sync,timestamp,cache2:5
(Assignee)

Comment 5

a year ago
(In reply to Honza Bambas (:mayhemer) from comment #3)
> Michal, this is hang in CacheFileAutoLock.  Please take a look ASAP.  Thanks.

There is no obvious reason why it should hang on the lock. It's not held by any other thread.
(Reporter)

Comment 6

a year ago
Created attachment 8781575 [details]
newlog.7z

As requested.
(Assignee)

Comment 7

a year ago
This is a dupe of 1279246. CloseWithStatus() is called on CacheFileInputStream [0x225081a0] while the input stream calls aWriter from ReadSegments. This re-enters the lock and its internal state gets corrupted.

We didn't uplift bug 1279246 because we thought it is limited to images compressed with brotli which is an unusual combination. Given that it's not true, we need to uplift it to beta.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1279246
You need to log in before you can comment on or make changes to this bug.