Firefox 49.0b3 on Windows 10, Anniversary Update If I open a treeherder link for a trybuild (e.g. ), 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  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. : https://treeherder.mozilla.org/#/jobs?repo=try&revision=83f22bd2efe0
Chris, can you please provide a log as described at ? Was this reproducible also in Win10 10586 (the pre-anniversary update version)?  https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging Thanks.
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)
Oh, it's an HTTP cache bug. Michal, this is hang in CacheFileAutoLock. Please take a look ASAP. Thanks.
Severity: normal → critical
Component: Networking → Networking: Cache
Chris could you please provide a log with following modules? NSPR_LOG_MODULES=sync,timestamp,cache2:5
(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.
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.