840062 - Losing connectivity when update is pending

Status: NEW

(Core :: Networking, defect, P3)

Description

[JDev]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130116073211

Steps to reproduce:

Logged into TrueAchievements.com - attempted to send a message via their forum software.  I was able to do GETs but not POSTs (TA uses JavaScript to initiate the POST)


Actual results:

Firefox reported "Connecting..." - "Waiting for www.trueachievements.com..." but did not respond.  I spoke with the developer of the site immediately, he verified everything was working properly.  Upon closing FF and re-opening there was an update to FF.  Upon applying the update and attempting to send the message again - everything worked without issue.

I have previously observed this behaviour on Win7 FF on other sites.


Expected results:

FF should have continued to operate as normal until I was ready to apply the update.

Comment 1

[JDev]

I should clarify:  The previously observed behaviour is that when there is an update waiting to be applied FF begins showing non-uniform connectivity issues.

Comment 2

[Ioana (away)]

Can you reproduce this issue in safe mode? What about with a clean profile?
http://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 3

[JDev]

Here's what I think is happening:  

An update is downloaded and sits there for a while, I tend not to close my browser (ever) so it can never be applied.  Something about this behaviour is causing some sort of hangup after the update sits there for an extended period.  It doesn't affect GET requests and I'm not sure if it's POSTs it's affecting or JavaScript POST or AJAX requests.

The browser I'm using is effectively a clean profile, it's a relatively new system that I avoided using (hate win8 ;) so I haven't had a chance to move my profile to yet so the only thing I installed was Adblock and Flash.

I'm not able to easily reproduce because I don't know how long the download needs to sit there before it causes the issue.  I have observed it on multiple systems (Win8 and Win7) and the behaviour is consistent (GET requests always work but submitting data becomes an issue) and I have observed it twice on this system - once with 18.01 and then again with 18.02.

Also, I should correct my previous statement:  I thought I had applied the update from 18.01 to 18.02 - this was not the case, I received the "firefox is still running error" upon restarting which somehow stopped the application of the update and allowed firefox to restart without re-attempting to apply the update.  This resolved the connectivity issues and I applied the update shortly after reporting this bug.

I'll try to keep an eye out when the next update rolls out but I'm not sure what information I can provide that would be helpful.

Comment 4

[JDev]

Further update.

I've now experienced this issue multiple times, as have several people I provide tech support for.  It has nothing to do with the type of request, simply that FF will stops network connectivity.  When this occurs there is always an update that applies after closing/restarting.  This never occurs outside of an upgrade cycle, only when an upgrade is pending/has not been applied for an extended period of time.

Comment 5

[JDev]

I've had another complaint regarding this issue where FF will become unresponsive and eventually crash every time there's an update.  Whether or not it's another issue presenting as this issue I cannot confirm, however, I was able to get the crash code after the latest instance.

bp-6c03697b-2250-4d7a-8df8-c069c2140922

Comment 6

[Robert Strong (they/them - no direct email)]

There is nothing in the crash report stack that points to app update so moving to untriaged so it can be filed correctly and then addressed.

Comment 7

[JDev]

Undoing changes.  This bug is for the issue relating to lack of connectivity/unresponsiveness whenever there is an update pending install.  If that crash can't be linked to it that's fine.  I'm just reporting what others are telling me/what I observe.  This particular user indicated to me that this type of hang occurs every time a new update is pending install and does not occur otherwise.  I cannot confirm that as fact only hearsay, nor can I confirm any relation between the crash and this bug.  I can only confirm that the ID listed was an instance of a hang/crash followed by an install of a new version consistent with what I was told by the user.

Comment 8

[Robert Strong (they/them - no direct email)]

Please do not change this again. You stated an "An update is downloaded and sits there for a while". I stated that there is nothing in the crash stack that indicates this is due to app update. The stack does indicate other code being where the problem is.

Comment 9

[Robert Strong (they/them - no direct email)]

In case it isn't clear, the failure in that code is likely what is responsible for the crash and the lack of network connectivity. Also, there are several other bugs that are similar in that same code. Even if somehow app update triggered which it doesn't appear to be the case from the stack the fix will likely need to be in code outside of app update.

Comment 10

[JDev]

My point was that the crash may have absolutely nothing to do with the bug.  By changing the title/flags to data specific to that crash you are misrepresenting the bug that I filed.  This user was not reporting the connectivity issues seen on several other systems, rather a hang/crash cycle in place of the connectivity issue.  I felt it was similar enough to include but should not replace the bug I filed.

Comment 11

[Nickolay_Ponomarev]

I'm changing summary back, based on comment 10, but it's still likely not related to the updater.

You say you rarely restart the browser, that's a more likely reason for losing connectivity and other aberrant behavior.

The crash you linked to was Firefox running out of memory. While crashing could be one symptom of running low on memory (or address space, which is quite probable for long-lived sessions in 32-bit apps), random functionality breaking could be another symptom.

At this point there's not enough information here to do anything on our end. Some suggestions on what you might try to do in order to figure this out:
- determine what specifically stops working (e.g.: any network requests? all sites? at the DNS level or any connectivity?)
- rule out interactions with system software (firewalls, AV, viruses) and Firefox customizations (add-ons, plug-ins), unusual network settings (proxy etc)
- do other apps still have network connection?
- how long does it take to get into this state? what's the firefox process stats at this point (RSS, virtual mem usage, about:memory reports)
- if the only thing affected is the network connectivity, perhaps https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging will help

And please don't treat this as if there's a single issue affecting you and the people you provide support for. It might well be a number of different issues.

Comment 12

[JDev]

The common issue between 3 systems (all Win7, 1 at one location, 2 at another) is the loss of connectivity, when an update is pending, that is local to Firefox.  A 4th system was the crash which maybe unrelated I'll address the comments in order:

- All connectivity within Firefox stops.  Other browsers work fine while the problem is occurring (IE/Chrome tested), ping/tracert/etc work fine as well.  Any request to any site, within Firefox, returns an error/try again and addons like Chatzilla stop functioning as well.
- 2 of the systems run without active firewalls/AV/etc and are clear of any known viruses/malware/etc (Panda Active Scan, Malwarebytes, Spybot, Defender all run with only tracking cookies found).  The 3rd system runs with Windows firewall and Avast! free.  Very vanilla network setups in both locations, Cisco/SmartRG routers in default configs.
- No other apps are affected.  Launched several to test (p2p, browsers, dropbox, etc) and none showed any issues with connectivity.
- How long it takes is unknown.  The user behaviour is to simply not shutdown Firefox unless required.  As such it's difficult to tell when the download starts/completes/time from completion to the issue.  The only known factor is that the only time this problem appears is when there is an update waiting to be installed.  With the bug occurring I've observed Firefox running at 494mb, 1.3gb, and 340mb with no unusual hdd/CPU spikes.  All systems have 4gb or more of RAM and no other 32-bit processes running that consume large amounts of memory.  (Notepad, Calculator, Windows Explorer, Sticky Notes, VLC, Kobo).  Nothing that would bring them close to the 2gb limit for 32bit processes.  Next time it occurs I'll get more data from wireshark/about:memory

Comment 13

[Nickolay_Ponomarev]

With a 32-bit process the process virtual memory can get fragmented leading to OOMs even though the process doesn't use much real memory.

I'm not sure what else you could check; the HTTP logs I suggested would probably take a LOT of space before the issue is reproduced...

Comment 14

[JDev]

An OOME would be logged in the system events log would it not?  If so I can look for it at the next occurrence.  

Also, I would assume FF has a failure routine when it's not able to allocate memory?

Comment 15

[Nickolay_Ponomarev]

> An OOME would be logged in the system events log would it not?
Not if the process has its virtual memory address space fragmented. The system might have enough memory, but the process is out of the address space. This should eventually result in a crash.

> Also, I would assume FF has a failure routine when it's not able to allocate memory?
It has, but it might fail.

When this happens again you could also check:
- error messages (the specific content of the network error page, browser console errors)
- whether loading from file:// and http://localhost (if you run a local HTTP server) works
- does the rest of functionality work? Loading a large local HTML (like the one from  https://html.spec.whatwg.org/) work?
- does toggling Work offline help?

Also, please attach the information from about:support the next time it happens.

Comment 16

[Abe - QA (:Abe_LV)]

User Agent 	Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Version 	46.0a1
Build ID 	20160112030207
Channel 	nightly

Thank you for taking time to report this.
Are you still able to reproduce this in the latest version ?

Comment 17

[JDev]

Yes, it seems to occur more frequently on lower end computers (our netbook and ~5 year old laptop).  On the netbook switching tabs becomes unstable/slow, loading pages becomes problematic, etc until the point of failing to respond or not loading pages.  On the laptop slow loading/instability happens until the 'restart now or later' screen pops up, however, when it does popup it's completely blank.  You can hover over where the buttons are supposed to be to get them to appear but the rest never shows up.  On that system the browser usually crashes shortly after selecting 'later' without a reporting window/error logged.

Upon restarting everything is magically fixed until the next pending update.

Comment 18

[JDev]

The problem is occurring right now on the more modern system.  43.0.2 is downloaded and pending and the browser has started becoming unresponsive in cycles.  It will stop responding for 20-30 seconds and then recover then loop this problem every few minutes.  Is there any data I can gather that will aid in isolating this bug?

Comment 19

[JDev]

End result: The browser eventually became so unstable that returning focus to it caused the Intel graphics to crash (has never happened before) and the browser was unable to recover (remained "Not Responding" and visually was blank).  The browser technically did not crash, I closed it normally and as a result no crash report was generated, however, upon restoring it did come up with the 'well that's embarrassing' restoration screen as if it had crashed.

43.0.3 is now downloaded and waiting to update.  It randomly spat out an error dialog message saying that it could not be installed and to check for FF processes.  Strangely it did this upon completing the download in an alert style dialog as I was restoring tabs from the crash.  Once the browser starts becoming unstable again I'll post details from comment 15 and any others that are requested.

For this occurrence:
> - error messages (the specific content of the network error page, browser console errors)
No console error messages

> - whether loading from file:// and http://localhost (if you run a local HTTP server) works
Loading a file worked

> - does the rest of functionality work? Loading a large local HTML (like the one from  https://html.spec.whatwg.org/) work?
Everything works, eventually, just pages will stop loading randomly/the browser hangs on loaded pages for a time.  On the i7 it's 20-30 seconds, on the i3 it's 1-2 minutes, on the netbook it's 2-3 minutes.

- does toggling Work offline help?
No, because the problem is primarily that pages will randomly stop loading so offline doesn't allow them to load.

I neglected to get the about:support data, I'll make sure I do it on the next round.

Comment 20

[JDev]

Attachment: Windows log of the application hang

Poking around I was able to find a windows event logged, attached .wer file with all the details it logged.

The program firefox.exe version 43.0.2.5833 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Action Center control panel.
 Process ID: fb0
 Start Time: 01d140f0246b2c21
 Termination Time: 55
 Application Path: C:\Program Files (x86)\Mozilla Firefox\firefox.exe
 Report Id: 15264519-bcbb-11e5-bee6-4c72b9d8b5f2
 Faulting package full name: 
 Faulting package-relative application ID: 

I also noticed I made an error in the previously mentioned FF version numbers.  43.0.2 should be 43.0.3 and 43.0.3 should be 43.0.4 - sorry about that.

Comment 21

[Abe - QA (:Abe_LV)]

Although this issue is not reproduced on my end, due to the amount of comments from developers, I will be changing the bug from Unconfirmed to New.

Comment 22

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 23

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258